ここには興味深い状況があります。Entity Framework でリポジトリ パターンを使用しているため、各データベース テーブルには、コンストラクターで DbContext のインスタンスを受け入れる独自の Repository クラスがあります。また、依存性注入に Ninject を使用しています。複数のリポジトリが DbContext を要求したときに、同じインスタンスが全体で使用されるように、特定の要求中にインスタンス化される単一のコンテキストを定義しました。これにより、UnitOfWork パターンに従うことができるため、複数のリポジトリで複数のことが発生し、1 回のコミットですべての変更がデータベースにコミットされます。
ここに問題があります。クライアント データを複数のデータベース (シャーディング) に分割する SQL Azure フェデレーションも使用しています。同じリクエスト内であるフェデレーション メンバー (データベース) から別のフェデレーション メンバー (データベース) にジャンプできる必要がありますが、注入されたコンテキストに依存する同じサービス/リポジトリ メソッドを使用できるようにしたいと考えています。最初に考えたのは、既存のコンテキストで USE FEDERATION sql コマンドを実行して次のデータベースに移動することでしたが、うまくいく場合とそうでない場合があるようです。ステートメントを実行すると、コンテキストの基礎となる接続が実際には新しいサーバーを指していることがわかりますが、何らかの理由で、そのコンテキストで実行されたクエリは以前の接続からの結果を返すことになります。複数のデータベースでコンテキストの同じインスタンスを使用することは、通常、新しいデータベースに接続するときに新しいコンテキストをスピンアップするため、ネイティブでサポートされているものではないと思います。残念ながら、Ninject を使用して動的に作成され、コンテキストの同じインスタンスを取得するリポジトリが多数あるため、新しいデータベースの新しいコンテキストをスピンアップしたとしても、既存のすべてのリポジトリを突然変更する方法はありません。最初のリクエストで作成されたものではなく、スピンアップしたばかりの新しいコンテキストに依存します。
考えられるいくつかの解決策を次に示しますが、それらを機能させる方法はわかりません。
- 既存のコンテキストで使用されているデータベースを変更します (上記で説明したように動作していないようでした)
- 既存のすべてのリポジトリが別のコンテキストに依存するようになるように、すべてのリポジトリの注入されたコンテキストを新しいものと交換します
- コンテキストが要求されたら、コンテキストに必要なパラメータを渡すすべてのリポジトリの新しいインスタンスを何らかの方法で Ninject に要求します。
繰り返しになりますが、ここでの要点は、単一のコンテキストに依存するリポジトリとサービスのセットがあり、それらのサービスとリポジトリを再利用できるようにしたいが、すべてが依存しているコンテキストを交換または変更して、新しいサーバー。