依赖注入容器

Question

我有一个数据访问层库，我想使其“可移植”。我喜欢它便携的原因是因为我想使用 SQL Azure 和 SQL Azure。 Azure 文件存储（例如，数据 + pdf 报告）以及具体服务器上的 Sql Server 2008R2 和文件系统存储。

根据规范，系统应该在后续实施（sql + 文件系统存储）中上线，而在满足一定的可扩展性阈值后，我们计划迁移到 Azure。

我使用的数据访问类实现了 IDataProvider 接口（我构建的），它定义了任何数据访问具体实现应该具有的方法。使用数据访问层是通过传递 IDataProvider 接口并调用其上的方法来完成的，例如：

public Interface IDataProvider
{
    public bool DoSomething();
}

public class AzureDataProvider : IDataProvider
{
    private string ConnectionString;

    public AzureDataProvider(string connectionString)
    {
        this.ConnectionString = connectionString;
    }

    public AzureDataProvider():this(
        ConfigurationManager.ConnectionString["conn"].ConnectionString)
    {
    }

    public bool DoSomething()
    {
        return false;
    }
}

所以现在的问题是调用 IDataProvider 接口上的方法的使用者类必须执行以下操作：

public class DataAccessConsumer
{
    public void SomeOperation()
    {
        AzureDataProvider azureProvider = new AzureDataProvider();
        IDataProvider dataProvider = (IDataProvider)azureProvider;

        bool result = dataProvider.DoSomething();
    }
}

所以上述代码的问题是客户端仍然必须了解具体的 AzureDataProvider 类。我想要一种只向客户端提供 IDataProvider 接口的方法，而不需要将连接字符串传递给每个接口方法，或者通过 ConfigurationManager 在每个方法中查找连接字符串。

这可能吗？抽象工厂或某种依赖注入容器模式可以解决这个问题吗？如果是这样，我将不胜感激代码示例或代码示例的链接。

Answer 1

首先，AzureDataProvider 依赖于 ConfigurationManager。这应该被注入。

其次，这个DataProvider应该被注入到DataAccessConsumer中。

这意味着现实的应用程序将具有良好的依赖项注入，而不依赖于容器，但是您将需要“接线” - 将所有依赖项连接在一起。这是一个痛苦 - 仅在主入口点使用 DependencyInjectionContainer 来帮助解决此连接问题。 （这允许您使用更方便的声明式方法而不是命令式方法，因为您可以询问容器“获取 DataAccessConsumer”，依赖项注入框架将为您找出依赖项。

我最喜欢的 C# 依赖项注入框架是 NInject2。

Answer 2

好吧，我推出了自己的 DI。如果目标是实现可移植性，那么我认为我已经找到了一个半可接受的解决方案。缺点是您无法真正实现完整的 DI，但在我的应用程序上下文中它已经足够好了。

连接接口：

public interface IConnection
{
    public string ConnectionString;
}

具体连接实现

public class Connection: IConnection
{
    public string ConnectionString{ get; set; }

    public Connection(string connectionString)
    {
        this.ConnectionString = connectionString;
    }

    public Connection():this(ConfigurtionManager.ConnectionStrings["connection"].ConnectionString)
    {
        //Broke DI in the interest of usability.
    }
}

数据访问层接口

public interface IDataProvider
{
    IConnection Connection;

    public void Foo();
}

具体数据访问层实现

public class AzureProvider : IDataProvider
{
    IConnection Connection { get; set; }

    public AzureProvider(IConnection connection)
    {
        this.Connection = connection;
    }

    public void Foo()
    {

    }
}

DI Container / Factory （单例或静态类）

public static class ProviderFactory
{
    public static IDataProvider GetProvider()  //I'd pass parameters if I had more than 1.
    {
        Connection connection = new Connection(); //this is why I broke DI.
        IConnection iConnection = (IConnection)connection;

        AzureProvider azureProvider = new AzureProvider(iConnection);
        IDataProvider iDataProvider = (IDataProvider)azureProvider;

        return iDataProvider;
    }
}

数据访问层消费者（在本示例中它是一个页面）：

public class SomePage : Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        IDataProvider provider = ProviderFactory.GetProvider();
        provider.Foo();
    }
}

如您所见，页面不需要知道任何实现细节数据访问层。只要ProviderFactory能够吐出IDataProvider，页面就开心了。因此，如果我们决定更改提供程序，例如SqlStorageProvider，只要它实现IDataProvider接口，则无需更改Page的代码。这在软件架构方面实现了真正的关注点分离。