こんにちは。ザクです。遅めの夏休みをとってリフレッシュしてきました。こう涼しいと夏休み感はゼロですね。 今日はCode Firstでモデル定義する際のリレーションシップの設定方法について書きます。こちらRailsほどちゃんとした情報がなくて大変困ったやつです。Microsoftさんにおかれましては、善処していただきたく存じます。 One-to-Manyリレーションシップ 簡単なのから行きます。1:Nの関係の場合です。 Creating an Entity Framework Data Model for an ASP.NET MVC Application (1 of 10) | The ASP.NET Site 前回紹介したチュートリアルで作成したモデルが早速そうなっています。StudentとEnrollmentの関係がそうですね。モデルのダイアグラム(Visual Studio 201
図 3 に示したシナリオでは、LINQ to Entities よりも Dapper を使う方が優れていることが簡単にわかります。しかし、SQL そのものを使うクエリにはわずかな違いしかないため、システム内でどちらでも使用できる特定のタスクを Dapper に切り替えることが妥当だとはかぎりません。普通、個人のニーズはさまざまで、EF クエリと Dapper の違いにこれが影響することもあります。ただし、Stack Overflow のように大量のトラフィックが行きかうシステムでは、1 回のクエリあたり数ミリ秒短縮するだけでも、かなりの効果があります。 永続化の他のニーズに対する Dapper と EF ここまでは、返される型のプロパティを正確に一致するすべての列をテーブルから取り出すだけのシンプルなクエリを測定してきました。では、クエリを型にプロジェクションする場合はどうなるでしょう。結
.NET Standard 2.0 EF Core が .NET Standard 2.0 対応になりました。つまり、.NET Core 2.0、.NET Framework 4.6.1、および .NET Standard 2.0 を実装するその他のライブラリで使えるようになりました。 サポート対象の詳細については、「Supported .NET Implementations」 (サポートされている .NET 実装) を参照してください。 モデリング テーブル分割 2 つまたはそれ以上のエンティティ型を同じテーブルにマッピングできるようになりました。そこで主キー列が共有され、各行が 2 つまたはそれ以上のエンティティに対応します。 テーブル分割を利用するには、テーブルを共有するすべてのエンティティ型の間で依存リレーションシップ (外部キー プロパティが主キーを形成する) を構成する必要が
EF Core 2.0リリースには批判すべき点が多いが、好ましい部分も少なくはない。本記事では、今回のリリースのハイライトをいくつか紹介する。 テーブル分割 ORMに対する一般的な批判は、効率の悪いデータ要求が実行される傾向のあることだ。ほとんどのORMがデフォルトで“SELECT *”クエリを実行するため、アプリケーションに必要なのがごく小さなサブセットであっても、データベースに対してすべての列が要求されることになる。 これまでのEFでは、これに対処する方法として、生成されるSQLを必要な列のみに限定する.Select句を使用していた。しかしこれには、サードパーティ製のマッピングライブラリ(AutoMapperのような)か、あるいは投影されたオブジェクト毎に必要な列を明示的にリストする必要がある。後者は面倒でエラーも起こしやすいので、先を急ぐ場合にはこのステップを省略することも多い。その
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く