EF（コードファースト）のコンテキストクラスの定義

質問

http://www.atmarkit.co.jp/fdotnet/ef4basic/ef4codefirst01/ef4codefirst01_02.html
こちらを参考にしてASP.net MVC + Entity Framework 4.1(コードファースト)
のWebシステムを作ろうと考えています。

既存のDBを使用することを考えていて、DBに含まれるテーブル数は100弱となります。

それぞれのテーブルに対応するエンティティクラスを100弱定義し、これらを
登録するコンテキストクラスを作成しようと考えたのですが、

１．コンテキストクラスも100弱定義し、web.configの接続定義も100弱定義する。
２．コンテキストクラスは1つ定義し、その中に100弱のエンティティの定義をする。
　　web.configの接続定義は1つ定義する

上記の１、２のいずれが方向性として正しいものでしょうか？

２のほうがすっきりするとは思いますが、データ取得時にコンテキスト・クラスのインスタンスを
生成する際、余計なエンティティ定義も読み込まれるためパフォーマンスが悪いような気もします。
無視していいほど軽いのであれば、間違いなく２の方法を取るのですが…。

回答No.1

aspnet · ベストアンサー

自分も似たような案件を考えており、私見を述べさせてもらいます。。
結論から言いますと、おっしゃる中間の方法がベストかと思います。

・データコンテキストクラスは意外と軽い
以前のDataSetに比べると、テーブルベースの属性が単純化されている関係で、オブジェクトサイズは半分以下になっています。
→以前ならリレーション取った10テーブルくらいでDataSetを分割していましたが、倍くらい収容してもさほどパフォーマンスは悪くならない。

・Connectionは共用できる
→１つでいい

・LINQ for Entity Frameworkでは、JoinやGroup Joinで容易にリレーションを再構築できる。
→常時緊密にリレーショナルなオブジェクトを生成しないものであれば、関連エンティティを複数のコンテキストに分割しても、上位DALのロジックはそれほど複雑化しない。ただし、過度に分割するのは禁物。

ということで、自分は

・Connection定義は１個を複数データコンテキストで使い回す

・リレーション系統を整理して、相互アクセス頻度の少ない「節」で切断し、データコンテキストを分ける。
データコンテキスト内は保守性や一覧性もあるので、20～25テーブル以下

あたりが一番スッキリするのではないかと思います。
１コンテキストにどの程度のテーブルが許容できるかは、リレーションと各テーブル対応クラスの複雑さによるので、何とも言えませんが。。100テーブルだと、保守性も悪いかと。

お礼

回答ありがとうございます。
・Connection定義の件
参考にしたサイトで、命名規則としてWeb.configのconnectionStringsにDbContextと同名の定義をすべきと
書かれていましたが、確かにご指摘の通り使いまわすのがよさそうです。context内に下記記述をして、明示的に使いまわすようにしました。
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
this.Database.Connection.ConnectionString =
System.Configuration.ConfigurationManager.ConnectionStrings["CommonDbConnection"].ToString();
}

・DbContext分割の件
確かに意味のある単位で適度に分割するのが良さそうです。
究極的にはmodel単位にDbContextを作成するということもありえますが、パフォーマンスと使い勝手を考慮する必要がありそうですね。

回答No.2

onos

このレベルでパフォーマンス考えたことないんですが。

コンテキストを分けたとき、複数のコンテキストにまたがる問い合わせを書いた場合にプログラムはJoin等を使ってすっきり書けても、実際のDBのへの問い合わせが複数回になってしまったり、本来絞り込んでとりだしたいデータが絞り込めない状態でメモリ上に載ってそこから絞り込みの操作がはいったり、といったことはないのでしょうか？

そのあたりも考慮する必要があるのかな、と思います。