1

マルチテナント (テナントごとのデータベース) アプリケーションを構築しています。

  • アプリケーション - .net MVC4
  • データ層エンティティ フレームワーク コードの最初のリポジトリ
  • リポジトリは、構造マップを介してアプリケーションに注入されます

構造マップ構成:

var connectionString = ConfigurationManager.ConnectionStrings["AccessControlDB"].ToString();

ObjectFactory.Initialize(x =>
    {
        x.For<IAccessControlContext>().Use<AccessControlContext>().Ctor<string>("connectionString").Is(connectionString);
        x.For<IGenericRepository<Identities>>().Use<GenericRepository<IAccessControlContext, Identities>>();
        x.Scan(scan =>
        {
            scan.AssembliesFromApplicationBaseDirectory();
            scan.ExcludeNamespace("StructureMap");
            scan.WithDefaultConventions();
        });
    });

各テナントをデータベースで分離するという新しい要件が発生したため、tenantID を持つだけでは十分ではなくなりました。

接続文字列を構築するために必要なデータを格納するためのメタ データベースを用意することはできましたが、接続文字列をリポジトリに渡す方法がわかりません。

最初は、接続文字列をプロパティとして公開するだけでよいと思っていましたが、構造マップによってコンテキストが既にインスタンス化された後に接続文字列を変更する方法はありません。

4

1 に答える 1

2

リポジトリに接続文字列を渡す代わりに、次の操作を行います。

  1. IContextFactoryをリポジトリに挿入します。このコンテキスト ファクトリは、新しいDbContextインスタンスを作成できます。
  2. ITenantProvider接続ファクトリに を注入します。

コンテキスト ファクトリをリポジトリに挿入すると、次の利点があります。

  1. 値がもたらすあいまいさを取り除き、stringその接続文字列を多くのクラスに挿入する必要がなくなるため、コンテナーの構成が大幅に簡単になります。
  2. ITenantProviderこれにより、接続文字列を解決する複雑さを抽象化の背後に隠すことができます。これは、コンテキスト ファクトリが (実装から取得したテナント情報に基づいて) 適切な接続文字列を作成する責任を負うようになったためです。
  3. DbContext接続文字列を返す代わりにファクトリから新しいインスタンスを返すことで、 DbContext. これにより、リポジトリが簡単になり、後で変更しやすくなります。

ここでは、リポジトリがどのように機能するかを推測しているだけなので、の使用はIContextFactory最適なオプションではない可能性があることに注意してください。しかし、接続文字列を直接注入することを防ぎ、抽象化の背後に隠すことで (接続文字列を返すだけでなく、それ以上のことを行うこともできます)、DI 構成とアプリケーション コードの両方を大幅に簡単にし、保守とテストを行うことができます。

于 2013-05-30T20:36:29.933 に答える