Q&A
使う側は自由に、実装方法色々ですよね。実際のベストプラクティスは、、、アプリケーションの規模、設計（そしてセンス）によりけりといったところでしょうか。
お世話になります。
DbContextを継承したコンテキストクラスが保持するプロパティについて、コンテキストクラスはどのような集合(Entityの集まり)とするべきでしょうか。
例えば、
・データベースそのものとし、使用するテーブル（Entity）をすべて定義する
・任意のまとまりとする（ex 画面（MVCではコントローラ）で使用するテーブルをプロパティに定義する 等）
・Entityと1対1（これはないでしょうが）
等々、ガイドライン的なものも見つけれなかったため、ご教授、もしくはご意見いただけますでしょうか。
よろしくお願いいたします。
回答3件
1
他の方の回答とダブるとことがありますが・・・
DB First でも Code First でも、好むと好まざるとにかかわらず、
・データベースそのものとし、使用するテーブル（Entity）をすべて定義する
ということにせざるを得ないと思います。
例えば、Microsoft が提供しているサンプルデータベース AdventureWorksLT から DB First で EDM を作る場合、
Visual Studio でプロジェクトに EDM を作成するには、項目の追加で ADO.NET Entity Data Model を使います。
ウィザードに従って .edmx ファイルを完成させると以下のようになります。
コンテキストクラスは以下のようになります。
投稿2018/10/25 07:36
総合スコア17927
1
Entity Framework 6.xの話です。
Entity Frameworkを使った構築の方法はモデルファースト、コードファースト、DBファーストとあります。
どれでも良いのですが、Entity FrameworkはDBの機能や.Netの機能の一部しか使えません。
ですから、Entity Frameworkを気分よく使おうとおもったらEntity Frameworkを使うことを前提としたモデリングが必要になってきます。
言ってみればEntity Framework-Firstですね。
そこで、ガイドライン的なものがあるのではと思うのもわからなくはないです。
しかし、モデリングに制約こそ多いですが、Entity Frameworkは単なる道具ですからDBの利用-構築まで言及することはあり得ません。
Entity FrameworkではDbContextに対してDbConnectionは一つだけで、DbSetは複数持てる
それだけです。
一つのデータベースに対して複数のDbContextがあってもかまいません。
個別のマイグレーションも可能です。
投稿2018/10/25 05:45
総合スコア4150
1
ベストアンサー
こんにちは。
ほぼEntityFrameworkCore専門なので、その観点での回答ですが。
DBからscaffoldしてみればわかりますが、1つのDbContextがDBそのものとなるのがまずは基本となります。これはアプリとDBが一対一となるような標準的なシステムの場合です。
もし、システム外のツールやコンソールアプリケーションを作る際に既存DBの一部を利用したいだけの用途であれば、必要最低限のカラムを持たせたテーブルマッピングクラスのみを手で書いてしまえば良いです。読むだけなら本当にデータが必要なカラムだけあればよく、書く場合はデータを入れなければならないカラムをもれなく定義します。
EFをマイグレーションに利用する予定があるなら、当然ですが1つのDbContextにDBの全情報を抜けなく定義しておく必要があります。
複数のプロジェクトにまたがって一つのDBを利用するなら、DBを完全マッピングしたDbContextとそのテーブルを表すクラスのみを持つアセンブリを作成しておき、それを使い回すというのも良いと思います。
とにかく、「1つのシステムが2種類以上のDbContextを利用することは決してない」ということを念頭に置いて考えてみると良いでしょう。
投稿2018/10/25 05:31
総合スコア4045
回答へのコメント
スキャフォールディング等、既存の機能ではDBと1:1の関係ですよね。
もしDBのテーブル数が多い（DBの設計うんぬんは置いておいてください）ような場合でも、コンテキストは1つのDBに対して1つのみとしますでしょうか。
もし1つのみの場合、多量のテーブルがあるDBのコンテキストクラスのインスタンスを生成した際、多くの不要なDbSetプロパティの無駄が出るのではないかと懸念しております。
EFはかなり手の広い基盤なので、機能を活かすとなるとDBと一対一にするのが基本となります。
EFの一部機能を利用して運用することを考える場合、DBと一対一というより「システムのデータレイヤと一対一」とすることを考えてください。
また、プロパティが多いDbContextのインスタンス化コストについては、EFを採用した時点で考えるだけ無駄という程度のものです。
EFを採用=コストがかかっているということで、EntityFrameworkのメタデータの読み込みあたりのコストに関係するということでしょうか。
検討違いの質問でしたら申し訳ありません。
EFを動作させる時点である程度以上の計算コストと資源コストが発生してしまうため、DbContextのプロパティ数を増やしたことによるコスト増など誤差程度の影響しか及ぼさない、という意味です。
返信遅くなり申し訳ありません。
なるほど、DbSetプロパティのコスト等は特に考慮せずによさそうですね。（するだけ無駄ですね）
参考になりました、ありがとうございました。
あなたの回答
tips
プレビュー
下記のような回答は推奨されていません。
このような回答には修正を依頼しましょう。
2018/10/26 00:41
2018/10/26 00:49
2018/10/26 01:06