1

私は依存性注入が初めてなので、次のシナリオをどのように処理するのだろうかと思っています。次のようなものがあります。

public class DatabaseContext
{
  public string ConnectionString {get;}
}

public interface IDataAccess
{
  string GetString(int id);
}

public class DataAccessImpl : IDataAccess
{
  private DatabaseContext _context;
  public DataAccessImpl(DatabaseContext context)
  {
    this._context=context;
  }

  public string GetString(int id)
  {
    return "some data";
  }
}

Web アプリケーションの場合、各リクエストは異なる DatabaseContext を構築して、異なるデータベースを指すことができます。Windows フォームの場合、現在の DatabaseContext を変更できます。di フレームワークは、変更可能な依存関係をどのように処理しますか? IDataAccess を要求すると、常に適切な/現在の DatabaseContext が含まれるようになります。

4

1 に答える 1

1

私が採用したアプローチは、DataContext を注入するのではなく、適切な型の DataContext を返すメソッドを持つクラスである DataContext ファクトリを注入することです。私の場合、デフォルトのコンストラクターであるコントローラークラスと、ファクトリー（および他の注入されたオブジェクト）を受け取るコントローラークラスの2つのコンストラクターがあります。デフォルトのコンストラクターは、すべてのパラメーターが null のパラメーターを使用してコンストラクターを呼び出すだけです。パラメーター化されたコンストラクターは、対応するパラメーターが null の場合、既定の型のオブジェクトを作成します。

ファクトリを使用すると、アプリケーションの存続期間全体にわたって存在する単一の DataContext を持つ代わりに、コントローラー アクションが呼び出されたときに新しい DataContext を作成できます。ファクトリは、利用可能な場合は既存のコンテキストを返し、必要に応じて新しいコンテキストを作成するように構築できますが、私はそれらを作業単位にスコープすることを好みます。

PSファクトリは、実際のDataContextではなく、DataContextのラッパークラスをインターフェイス（IDataContextWrapper）として実際に生成します。これにより、コントローラー テストから実際のデータベースを簡単にモックできます。上記はすべて LINQ/ASP.NET MVC を前提としていますが、原則は一般的に適用できると思います。

于 2008-11-08T13:51:11.247 に答える