依赖注入

OOP中的对象通常依赖于其他对象。也就是说，类引用其他类，因为它们需要使用它们来完成自己的工作。

例如，假设我们有一个类Customer。Customer对象能够使用GetDetails()方法从数据库中检索详细信息。

public class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }
    public Customer()
    {
    }
    public void GetDetails()
    {
        Database db = new Database();
        return db.GetCustomer(this.Id).Details;
    }
}

这太糟糕了CCD_ 4和CCD_。这意味着Customer对Database了解太多；它完全依赖于它。

如果Database对象具有更多的构造要求，则问题会加剧。

想象一下：

public void GetDetails()
{
    Database db = new Database("localhost", "3306", "username", "password", "database");
    return db.GetCustomer(this.Id).Details;
}

情况更糟现在Customer类做得更多。如果每个类都在创建一个Database对象，那么很快就会变得很难看。这很难维护，如果Database类发生更改，代码就会中断。假设我们不再需要在对象的构造中提及端口，或者我们可能添加了更多的参数。

最终，Customer类不应该对数据库有太多了解。真的，它不在乎。它只是想使用数据库。

让我们将Customer更改为使用依赖项注入。

public class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }
    private IDatabase db { get; set; }
    public Customer(IDatabase db)
    {
        this.db = db;
    }
    public void GetDetails()
    {
        return db.GetCustomer(this.Id).Details;
    }
}

这种技术被称为构造函数注入。我们正在通过构造函数注入一个依赖项。现在Customer不知道是什么类型的数据库，它是如何创建的，也不知道关于它的任何事情。Customer只知道它符合IDatabase接口和接口提供的方法。太棒了

使用哪个DI容器

但我很困惑哪一个是最好的。

对于像你我这样的人来说，这其实并不重要。他们做同一件事的方式略有不同。除非你有一个胜过另一个的理由，否则选择一个易于使用、受欢迎且有大量(社区(支持的。

就我个人而言，我使用温莎城堡。我听说过关于Ninject、Autofac、StructureMap和Unity的好消息。

IoC与DI

IoC表示控制反转。

DI表示依赖注入。

依赖注入是实现控制反转的一种方法。也就是说，DI是IoC的一种技术。

在我们的Customer类示例中，它创建并管理一个Database对象。CCD_ 19对象是控制CCD_ 20对象。

当我们实现依赖项注入时，我们反转了该控制，或者反转，以便在其他地方处理对Database的控制。

为什么

使(例如(控制器可测试。

如何

通过构造函数将所有外部依赖项(如数据库访问(注入控制器。

这个原理被称为依赖注入，您实际上不需要容器/框架来使用它。事实上，对于我从不做的小项目(开销对我来说有点重(，我只使用这样的东西：

public class MyController : Controller
{
    private readonly IDependency _dependency;
    public MyController ()
        : this(new ActuallImplementationOfDependency())
    {
    }
    public MyController (IDependency dependency)
    {
        _dependency = dependency;
    }
    // ...

}