c# - 依赖注入(inject)有什么大的改进？

Question

目前我正在尝试更好地理解依赖注入(inject)，并且我正在使用 asp.net MVC 来处理它。您可能会看到我提出的其他一些相关问题；)

好吧，我将从一个示例 Controller (一个示例 Contacts Manager asp.net MVC 应用程序)开始

public class ContactsController{

  ContactsManagerDb _db;

  public ContactsController(){

    _db = ContactsManagerDb();

  } 

  //...Actions here
}

好吧，太棒了，一切正常。我的操作都可以使用数据库进行 CRUD 操作。现在我决定要添加单元测试，并且添加了另一个构造函数来模拟数据库

public class ContactsController{

  IContactsManagerDb _db;

  public ContactsController(){

    _db = ContactsManagerDb();

  }

  public ContactsController(IContactsManagerDb db){
    _db = db;
  }

  //...Actions here
}

太棒了，这很有效，在我的单元测试中，我可以创建我自己的 IContactsManagerDb 实现并对我的 Controller 进行单元测试。

现在，人们通常会做出以下决定(这是我的实际问题)，摆脱空 Controller ，并使用依赖注入(inject)来定义要使用的实现。

因此，我使用 StructureMap 添加了以下注入(inject)规则:

x.For<IContactsManagerDb>().Use<ContactsManagerDb>();

当然，在我的测试项目中，我使用了不同的 IContactsManagerDb 实现。

x.For<IContactsManagerDb>().Use<MyTestingContactsManagerDb>();

但我的问题是，**在这种特定情况下，通过使用依赖注入(inject)，我解决了什么问题或简化了什么问题”

我现在看不到它有任何实际用途，我明白如何但不明白为什么？这有什么用？任何人都可以添加到这个项目中，举例说明这如何更实用和有用吗？

Answer 1

第一个示例不可单元测试，因此它不是很好，因为它在应用程序的不同层之间创建了强耦合并降低了它们的可重用性。第二个例子叫做 poor man dependency injection .还讨论了here .

可怜的依赖注入(inject) 的问题在于代码不是自动记录的。它没有向消费者说明其意图。消费者看到这段代码，他可以很容易地调用默认构造函数而不传递任何参数，而如果没有默认构造函数，就会立即清楚这个类绝对需要将一些契约传递给它的构造函数才能正常运行。而且真的不是由类来决定选择哪个具体实现。这取决于此类的消费者。