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 的方法的类。我有两个构造函数，在我的例子中，一个控制器类是默认构造函数，另一个是使用工厂（和其他注入对象）。默认构造函数只是简单地调用带有参数的构造函数，并且所有参数都为空。如果相应的参数为空，则参数化构造函数会创建默认类型的对象。

使用工厂允许我的控制器操作在调用时创建一个新的 DataContext，而不是在应用程序的整个生命周期中都存在一个 DataContext。可以构建工厂以返回现有上下文（如果可用）并根据需要创建新上下文，但我更喜欢将它们限定为工作单元。

PS 工厂实际上产生了一个围绕 DataContext 的包装类，而不是实际的 DataContext，作为接口（IDataContextWrapper）。这使得从我的控制器测试中模拟实际数据库变得更加容易。以上所有都假设 LINQ/ASP.NET MVC，但我认为这些原则是普遍适用的。

于 2008-11-08T13:51:11.247 回答