私は非常に大きなデータベース、約80個のテーブルを持っています。だから私は1つの大きなedmxファイルで80のテーブルをすべて持つのではなく、テーブルを限定されたコンテキストに分割することに決めました。複数のエンティティ・フレームワーク・バウンド・コンテキストに同じテーブルを追加しますか？
だから、私は私の顧客EDMXファイル内の私のメインの顧客テーブルを持っているなどの販売、顧客、などの状況に
有界います。しかし、Sales edmxコンテキストのcustomerテーブルからは、すべてではなく、1つまたは2つのフィールド（たとえば、カスタマーオブジェクト/テーブル全体ではなく顧客名が必要なフィールド）にアクセスする必要もあります。
Sales Edmxファイルに顧客テーブル全体を追加する必要がありますか？このシナリオのベストプラクティスは何ですか？
このアプローチには根本的な問題のカップル（IMO）があります
EFは、任意のORMのように、永続性の懸念に落ちます。このように、ドメインモデルの構造を妨げてはいけません。 1つの永続ストアのように聞こえるようにすべてのエンティティを永続化しているという事実は、境界のあるコンテキストが重複しているか存在していないことを示す可能性があります。
より良い構造に移行しようとするのは悪いことではありません:)しかし、Mark Oreta氏が述べたように、私はおそらくEF構造を気にしません。
実行中の主な問題は、ドメインモデルからの読み取りを試みたことが原因です。これはシステムであまりにも頻繁に切り詰めているように見えます。レイジーローディングはまさにこれの直接的な結果です。読んでいるときは理想的には、読み込み用に最適化されたクエリストア（同じデータベースかもしれない）へのアクセスを持つクエリレイヤーを使用してください。あなたの例では、あなたの販売ドメインに非正規化された顧客名が必要です。それは結構です。あなたのドメインモデルを読んでそれを取得しようとすると、別の制限されたコンテキストでドメインモデルからデータを取得しようとすると、あなたの痛みの原因になります。
データを分割するルートを下った場合は、を分割したままにする必要があります。
さまざまなBCのデータはすべて同じストアにあるかもしれませんが、各BCに独自のデータベースがあるようにデータを考えるべきです。時には私は、異なるフォルダ/名前空間（ここでは.NET）にさまざまな懸念（いくつかのレイヤー）がある単一のプロジェクトを持っています。これらの懸念事項を別々のアセンブリに分割することは可能です。だから彼らはあまりにも緊密に結合すべきではありません。分割しようとしているデータ構造についても同じことが言えます。本質的に、関連BCデータを別のデータベースに分割することができます。 BC間でデータを取得するための仕組みは別の問題であり、それが解決できない場合は難しいと感じるかもしれません。
私はデータ側からのBCを識別することは、それは確かに正しい方向への一歩である最高のアイデア:)
ナビゲーションプロパティ（Sale.Customer）を使用してSalesエンティティからCustomerエンティティにアクセスしたい場合は、sales edmxに追加する必要があります。
すべてのテーブルを1つのedmxに作成することは、作成し、必要なアクションに使用し、それを破棄した場合、オブジェクトグラフはそれを大きくする。
また、バインドされたコンテキストを保持したい場合は、リポジトリや、必要なときにIDでフェッチすることもできます。
var customer = customerContext.GetCustomerById(sale.CustomerId);
かもしれないと思うが、私はhttp://msdn.microsoft.com/en-us/magazine/jj883952.aspx
このトピックのジュリー・ラーマンの見解を好きI生成されたビューを使用していても、より小さなdbcontextを使用すると、コンテキストのロード時間が速くなるため、アクセス・パフォーマンスに制限付きのコンテキストを使用します。アクセスモデルをシンプルにするのは素晴らしいことです。 パフォーマンスは、MS efサイトのヒントを考慮してください：http://msdn.microsoft.com/en-us/data/hh949853
BCは、ビジネス上の問題に合わせてアクセスを制限するなどの他の利点も認めています。 DBSetが表示されるだけでなく、モデルビューを変更しようとするだけでなく、さまざまなDBコンテキストを使用しようとすると、より大きな問題が発生します。私はそれがEFの外で行われ、マップされるのが最善だと思います。
大規模なSUPERSETコンテキストを使用して、DBの作成/移行を管理します。しかし、日々のアクセスはありません。
小さなDBコンテキストは、データへの毎日の1日アクセスに使用されます。
したがって、すべての意味では、限定されたコンテキストを使用してください。これは、SAMEデータストアに対して行うことができます。 そしては、多くの状況で表示されることが文言「はい、同じテーブル（DbSet）として質問に答える。
複数のコンテキストに同じエンティティを追加するとき、特にEFが慣習でナビゲーションプロパティを取得するときに、エンティティ設定を管理するにはどうしたらいいですか？私は問題[ここ]（http://stackoverflow.com/questions/18486699/entity-configuration-management-with-ddd-bounded-contexts）に関するさらに詳しい情報があります。 –
残念なことに、 'ignore'プロパティやテーブルが十分ではなく、特定のテーブルで異なるナビゲーションオプションが必要な場合は、ベースクラスNO navが必要です。 Class1：NVAが追加されたベースおよびNavがないクラス2。あなたはその特定の要件を持っている場合、その側面は痛いですが、やむを得ないです。 –
だから、それは良いことだので、私は私の販売BCに顧客を追加する場合、それは本当に問題ではありませんが、言っています –
また、私が販売ドメインに正規化されていない顧客名が必要な場合は、Salesテーブルに別の列CustomerNameを追加する必要があるのか、それとも追加する必要があるのですか？ –
顧客の販売ドメインに顧客を追加すると、それはデータを提供しているだけなので、VOになり、あなたは全くそれと対話しません。 Salesドメインの「Customer」にはIDとFullNameのみが含まれている可能性がありますが、CustomerエンティティをSalesドメインに「プル」しないでください。 d販売ドメインの非正規化顧客名を選択します。もちろんそれはすべてコンテキストに依存します:) –