Entity Framework Development LeadであるSrikanth Mandadi氏が「Entity Frameworkで規模の大きいモデルに取り掛かる」という2章からなる記事を取り上げ、明らかにそれに「対処する」ことを意味していると話している。 その記事は、任意のアプリケーションで予想されるエンティティ数(たったの50から100)から始まる。その他に、エディタは事実上、使用に適さなくなっている。
Entity Frameworkには、驚くほど明白なパフォーマンス上の問題がある。たとえば、データモデル全体にのXMLベースのメタデータが、新たに接続ストリングが使用されるごとに、メモリにロードされる。共用データモデルを共有する一連の小さいアプリケーションがある場合、新しくエンティティを追加すると、全体的に速度が低下する。この制限により、共用ライブラリにEntity Frameworkデータモデルを配置することが基本的に支持できなくなっている。
ビューの生成は、Entity Frameworkの設計で著しく不足していると判明した分野である。Srikanth Mandadi氏は、以下のように説明する。
クエリーもしくはSaveChangesが 初めて発生した場合に、そのプロセスは実行する。ビューの生成過程のパフォーマンスは、モデルのサイズだけでなく、モデルがどのように相互接続されるかにも依存する。2つのエンティティが継承チェーンもしくはAssociationを通じて接続される場合、それらは接続されていると言える。同様に、2つのテーブルが外部キーで接続される場合、それらは接続されている。スキーマにある接続済みのエンティティやテーブルが増加するにつれて、ビュー生成のコストが増加する。
こうした問題に取り組むために、Srikanth Mandadi氏は大きなデータモデルを小さいサブセットに分割することを提案している。これには2通りの方法がありうるが、そのどちらも不適切である感じがする。
1つ目は、全く別のサブセットを使うことである。複数のサブセットでテーブルが必要とされている場合、それぞれに対し別のエンティティが作成される。そうすると、サブセット全体で直接呼び出すことができなくなり、膨張につながる。
別の選択肢は、スキーマで構文を「使用する」ことである。IDEは、これをサポートしない。手動でXMLを編集して、1つのデータベースが、別のデータモ デルからのエンティティを使用しなければならない。手でXMLを編集することの面倒は別として、これは片方向のリンクのみを作成することができる。データ モデルAがデータモデルBからのエンティティを使用している場合、データモデルBは、データモデルAに戻っての参照はできない。
ADO.NET Team Blogで、パート1(リンク)およびパート2(リンク)のすべてを読むことができる。