Entity Frameworkを使用したことがある場合は、EDMXが優れていることをご存知でしょう。また、それが巨大になり、ほとんど管理できなくなる可能性があることも知っています。
大きくなると、2番目または3番目のEDMXを作成したくなります。データベース内のスキーマごとに1つでも作成できます（例として）。
このような分離はEDMXの編成に役立ちますが、同じ名前空間内のエンティティのコンテキストを分離する可能性があります。
さらに、個別のEDMXファイルは、EDMXファイル間でのJOIN操作により、過剰で冗長なデータベース通信が発生する状況を引き起こす可能性があります。
しかし、EDMXが大きいほど、使用が難しくなるという事実は変わりません。それが正しいことを確認することはより困難です。壊れやすいです。
EDMXファイルを分解しますか？いつそれを行うかについての経験則はありますか？
EDMXを分割する必要がある1つの例は、複数のプロジェクトで使用されるエンティティのグループがあり、他のエンティティはプロジェクト固有であり、パーツ間にナビゲーションプロパティを持たないことをいとわない場合です（公開されたFK）。
個別に保守する場合は、EDMXを自動的に1つにマージできますが、それらすべてのコンテキストを開いて、1つとしてクエリを実行します。これには、同じ名前空間を共有する必要があります。
1つのソリューションで2つの別々のEDMXを使用する必要がある場合に限ります。この分離は、ドメイン固有のモデルエンティティ用のEDMXと、すべてのソリューションでより一般的なもの（例として支払い）で発生しました。論理的には、これはデータベーススキーマレベルであったと言えますが、それは分離の難しいルールではありませんでした。
それらをまたがる結合の要件はありませんでしたが、トランザクションが必要でした。これは、TransactionScope内でEFコンテキストをラップする再利用可能なUnitOfWorkContainerを使用して実現しました。コンテキストはDIを介してコンテナーに注入され、コンテナーに複数のコンテキストが保持されている場合にのみTransactionScopeを使用します。
コンテナー自体がIUnitOfWorkインターフェースを実装したため、既存のコードベースにプラグインするのは非常に簡単でした。