EntityFrameworkにおけるDbContextについて

Question

お世話になります。
DbContextを継承したコンテキストクラスが保持するプロパティについて、コンテキストクラスはどのような集合(Entityの集まり)とするべきでしょうか。
例えば、
・データベースそのものとし、使用するテーブル（Entity）をすべて定義する
・任意のまとまりとする（ex 画面（MVCではコントローラ）で使用するテーブルをプロパティに定義する 等）
・Entityと1対1（これはないでしょうが）
等々、ガイドライン的なものも見つけれなかったため、ご教授、もしくはご意見いただけますでしょうか。
よろしくお願いいたします。

Answer 1

他の方の回答とダブるとことがありますが・・・

DB First でも Code First でも、好むと好まざるとにかかわらず、

・データベースそのものとし、使用するテーブル（Entity）をすべて定義する

ということにせざるを得ないと思います。

例えば、Microsoft が提供しているサンプルデータベース AdventureWorksLT から DB First で EDM を作る場合、

Visual Studio でプロジェクトに EDM を作成するには、項目の追加で ADO.NET Entity Data Model を使います。

ウィザードに従って .edmx ファイルを完成させると以下のようになります。

コンテキストクラスは以下のようになります。

Comments

[f_horizon]

大規模DBを扱う場合にコンテキストクラスをどのように位置づけるのかが気になっていたのですが、やはり基本1対1ということなんですね。
割とそうではないサンプルもあるため、業務レベルでの実際のところはどうなのかなと思った次第でした。ありがとうございました。

[退会済みユーザー]

> 割とそうではないサンプルもあるため
どういうものでしょう？　ネットに公開されているもので、信頼が置けそうなサイト・記事であれば URL を紹介していただけませんか？

[f_horizon]

命名等も特にDBを意識したものでもなく、私がそういう印象を受けなかった、といった方が正しいですね。
またここへの掲載はご遠慮させていただきます。

Answer 2

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があってもかまいません。
個別のマイグレーションも可能です。

Comments

[f_horizon]

使う側は自由に、実装方法色々ですよね。実際のベストプラクティスは、、、アプリケーションの規模、設計（そしてセンス）によりけりといったところでしょうか。

[hihijiji]

RDBMSに実装されていることが多いDBスキーマと対応させるとか、マスタメンテと通常運用に分けるとか色々分け方はありそうです。
とか言いながら私もほとんどは DataBase 1つに対して DbContext 1つになってます。

[f_horizon]

なるほど、、、スキーマや1つのアプリケーションに対し複数のDBが絡んでくるとまた検討した方がよさそうですね。
とりあえず、変にまとめてて後から使いにくくなりそうなので、私もDBと1対1を基本方針で設計してみます。
ありがとうございました。

Answer 3

こんにちは。
ほぼEntityFrameworkCore専門なので、その観点での回答ですが。

DBからscaffoldしてみればわかりますが、1つのDbContextがDBそのものとなるのがまずは基本となります。これはアプリとDBが一対一となるような標準的なシステムの場合です。

もし、システム外のツールやコンソールアプリケーションを作る際に既存DBの一部を利用したいだけの用途であれば、必要最低限のカラムを持たせたテーブルマッピングクラスのみを手で書いてしまえば良いです。読むだけなら本当にデータが必要なカラムだけあればよく、書く場合はデータを入れなければならないカラムをもれなく定義します。

EFをマイグレーションに利用する予定があるなら、当然ですが1つのDbContextにDBの全情報を抜けなく定義しておく必要があります。

複数のプロジェクトにまたがって一つのDBを利用するなら、DBを完全マッピングしたDbContextとそのテーブルを表すクラスのみを持つアセンブリを作成しておき、それを使い回すというのも良いと思います。

とにかく、「1つのシステムが2種類以上のDbContextを利用することは決してない」ということを念頭に置いて考えてみると良いでしょう。

Comments

[f_horizon]

スキャフォールディング等、既存の機能ではDBと1:1の関係ですよね。
もしDBのテーブル数が多い（DBの設計うんぬんは置いておいてください）ような場合でも、コンテキストは1つのDBに対して1つのみとしますでしょうか。
もし1つのみの場合、多量のテーブルがあるDBのコンテキストクラスのインスタンスを生成した際、多くの不要なDbSetプロパティの無駄が出るのではないかと懸念しております。

[tamoto]

EFはかなり手の広い基盤なので、機能を活かすとなるとDBと一対一にするのが基本となります。
EFの一部機能を利用して運用することを考える場合、DBと一対一というより「システムのデータレイヤと一対一」とすることを考えてください。
また、プロパティが多いDbContextのインスタンス化コストについては、EFを採用した時点で考えるだけ無駄という程度のものです。

[f_horizon]

EFを採用=コストがかかっているということで、EntityFrameworkのメタデータの読み込みあたりのコストに関係するということでしょうか。
検討違いの質問でしたら申し訳ありません。

[tamoto]

EFを動作させる時点である程度以上の計算コストと資源コストが発生してしまうため、DbContextのプロパティ数を増やしたことによるコスト増など誤差程度の影響しか及ぼさない、という意味です。

[f_horizon]

返信遅くなり申し訳ありません。
なるほど、DbSetプロパティのコスト等は特に考慮せずによさそうですね。（するだけ無駄ですね）
参考になりました、ありがとうございました。