私はかなり大きなデータベースを持っており、約 80 個のテーブルがあります。そのため、1 つの大きな edmx ファイルに 80 個のテーブルすべてを含めるのではなく、テーブルを境界付けられたコンテキストに分割することにしました。
そのため、Sales、Customers などのコンテキストを制限しました。
Customers edmx ファイル内にメインの顧客テーブルがあります。ただし、Sales edmx コンテキストの顧客テーブルから、すべてではなく、1 つまたは 2 つのフィールド (たとえば、顧客オブジェクト/テーブル全体ではなく、顧客名のみが必要) にアクセスする必要もあります。
顧客テーブル全体を Sales edmx ファイルに追加する必要がありますか? このシナリオのベスト プラクティスは何ですか?
このトピックに関するジュリー・ラーマンの見解が好きですhttp://msdn.microsoft.com/en-us/magazine/jj883952.aspx
生成されたビューを使用する場合でも、小さい dbcontexts を使用するとコンテキストの読み込み時間が速くなるため、アクセス パフォーマンスのために境界付けられたコンテキストを使用します。アクセス モデルを単純化することは、非常に便利です。パフォーマンスについては、MS ef サイトのヒントを考慮してください: http://msdn.microsoft.com/en-us/data/hh949853
BC には、ビジネス上の問題に対応するためのアクセス制限など、その他の利点もあります。DBSet が表示されるだけでなく、Model ビューを変更しようとしても異なる db コンテキストを操作しようとすると、より大きな問題が発生します。私はそれがEFの外で行われ、マッピングされるのが最善だと思います。
1 つの大きな SUPERSET コンテキストを使用して、DB の作成/移行を管理します。しかし、毎日のアクセスではありません。
小さい DBcontext は、データへの毎日の終日のアクセスに使用されます。
したがって、必ず境界付きコンテキストを使用してください。これは、 SAME データ ストアに反する可能性があります。そして、「はい、同じテーブル ( DbSet)が多くのコンテキストで表示される可能性があります。
このアプローチ（IMO）には、いくつかの根本的な問題があります。
EFは、他のORMと同様に、永続性の問題に分類されます。そのため、ドメインモデルの構造を妨げることはありません。すべてのエンティティが1つの永続化ストアのように永続化されているという事実は、制限されたコンテキストが重複しているか、存在しないことを示している可能性があります。
より良い構造に移行しようとすることは悪いことではありません:)---しかし、Mark Oretaが述べたように、私はおそらくEF構造を気にしないでしょう。
あなたが遭遇している主な問題は、あなたのドメインモデルから読み込もうとすることによって引き起こされます。これはシステムで頻繁に発生するようであり、物事をかなり困難にします。遅延読み込みは、まさにこれの直接的な結果です。読むときは、理想的には、読むために最適化されたクエリストア（同じデータベースの場合もあります）にアクセスできるクエリレイヤーを使用する必要があります。あなたの例では、販売ドメインに非正規化された顧客名が必要です。それは結構です。ドメインモデルを読み取ってから、別の制限されたコンテキストでドメインモデルからデータを取得しようとすることで、それを取得しようとすると、問題が発生します。
データを分割するルートをたどる場合は、データを分割しておく必要があります。
さまざまなBCからのデータがすべて同じストアにある場合でも、各BCに独自のデータベースがあるかのようにデータを考える必要があります。時々、私は異なるフォルダ/名前空間（ここでは.NET）にさまざまな懸念（いくつかのレイヤー）を持つ単一のプロジェクトを持っています。それらの懸念を気まぐれで別々のアセンブリに分割することが可能であるはずです。したがって、それらはあまり緊密に結合されるべきではありません。分割しようとしているこのデータ構造についても同じことが言えます。本質的には、関連するBCデータを別のデータベースに分割できる必要があります。BC全体でデータを取得するためのメカニズムは別の問題であり、それに対処できない場合は、難しいと感じるかもしれません。
データ側からBCを特定するのが最善のアイデアではないと思いますが、それは確かに正しい方向への一歩です:)
ナビゲーションプロパティを使用してSalesエンティティからCustomerエンティティにアクセスできるようにする場合は、（Sale.Customer）それをsalesedmxに追加する必要があります。
すべてのテーブルを単一のedmxに含めることは必ずしも悪いことではありません。テーブルを作成し、必要なアクションに使用し、それを破棄する限り、オブジェクトグラフはそれほど大きくなりません。
あるいは、制限されたコンテキストを保持したい場合は、必要なときにリポジトリなどでIDによってフェッチすることができます。
var customer = customerContext.GetCustomerById(sale.CustomerId);