ソリューションを複数のプロジェクトに分割する場合、複数のデータ コンテキストを使用したり、コンテキストを共有したりすることは理にかなっていますか?
たとえば、次のような Web ポータルがあります。
App.Service1
App.Service2
App.Web (references Service1 and Service2)
Service1 と Service2 が同じ DataContext を共有するようにしますか、それともそれぞれ独自の DataContext を持つようにしますか?
Service1との両方Service2がまったく同じデータベースに接続していることに注意してください。これらは、物事をより分離するために分離されているだけです。
私はEF6を使用しています。
同じコンテキストを共有することをお勧めします。複数のコンテキストは、異なるデータベースからデータを集約する場合に意味があります。
2 つのコンテキストが同じデータベース上に存在する場合、移行またはスキーマの変更検出と混同するために Entity Framework を停止するため、主に単一のコンテキストを使用します。
分離が懸念事項であり、設計でそれが可能な場合は、コンテキストに Service1 と Service2 の論理的な分割である 2 つのインターフェイスを実装し、コード全体でインターフェイスを使用します。
また、ナビゲーション プロパティに関してクロス コンテキストの関係を持つことはできないことに注意する価値がありますが、それは問題のようには聞こえません。
一般に、簡単にするために 1 つのコンテキストを使用することをお勧めしますが、データ モデル (コンテキスト) が非常に大きい場合は、複数のコンテキストを使用するとパフォーマンスが向上する可能性があります。ただし、エンティティに関係がない場合にのみ意味があります。また、多くのコンテキストを処理することは困難な場合があります。
個人的には、同じデータベースで 2 つのデータ コンテキストを使用しても意味がないと思います。物事を分離するというあなたの考えはわかりますが、EFはこのようにしないほど強力だと思います。@Darinが言ったように、異なるデータベースに2つのコンテキストを使用します。