私は、100 を超えるモジュールと、データベース内のほぼ 500 のテーブルを含む非常に大規模なアプリケーションに取り組んでいます。Entity Framework 4.2 Code First を使用して、このアプリケーションを WPF/WCF に変換しています。私たちのデータベースは SQL Anywhere 11 です。データベースのサイズのため、 Julie Lerman によるhttp://msdn.microsoft.com/en-us/magazine/jj883952.aspxで説明されているように、Bounded DbContexts と同様のアプローチを使用しています。 . 各モジュールは独自の DbContext を作成し、必要なデータベースのサブセットのみをモデル化します。
しかし、DbContext の作成方法に深刻な問題が発生しました。私たちのモジュールは自己完結型ではなく、自己完結型でもありません。一部のモジュールには、他の複数のモジュールから呼び出される操作が含まれています。その場合、呼び出しモジュールによって開始されたトランザクションに参加する必要があります。(また、アーキテクチャ上の理由から、DTC はオプションではありません。) 古い ADO アーキテクチャでは、トランザクションをサポートするためにモジュールからモジュールへオープン接続を渡すことに問題はありませんでした。
私はさまざまな DbContext コンストラクターのオーバーロードを調べ、EntityConnection と StoreConnection からトランザクションを管理しようとしましたが、私が知る限り、ModuleA がトランザクションを開始し、ModuleB で関数を呼び出して、 ModuleB の DbContext がトランザクションに参加します。
それは次の 2 つの簡単なことに帰着します。
ケース 1. DbContextA の EntityConnection を使用して DbContextB を構築すると、DbContextB は独自のモデル メタデータを使用して構築されません。DbContextA のメタデータを再利用します。コンテキストには異なる DbSet のコレクションがあるため、ModuleB のクエリはすべて失敗します。(エンティティ タイプは現在のコンテキストの一部ではありません。)
ケース 2. ModuleA の StoreConnection で DbContextB を構築すると、DbContextB は EntityConnection レベルで StoreConnection の開いているトランザクションを認識しないため、ModuleB が SaveChanges() を呼び出すと、EF は新しいトランザクションを開始しようとします。実際、データベース接続には開いているトランザクションがあるため、これによりデータベース例外が生成されます。(接続は並列トランザクションをサポートしていません。)
1) ケース 1 で DbContextB に独自のモデルを強制的に構築させる方法、または 2) ケース 2 で DbContextB の ObjectContext を取得して StoreConnection のトランザクション状態を尊重させる方法はありますか?
(ちなみに、私は EF6 アルファ版で心強いものを見ましたが、テストした後、唯一の違いは、開いている接続で DbContextB を作成できることでした。それでも、上記の 2 つの問題は依然として存在します。)