依赖注入有哪些重大改进？

Question

目前我正在尝试更好地理解依赖注入,我正在使用asp.net MVC来处理它.你可能会看到我的一些其他相关问题;)

好吧,我将从一个示例控制器(示例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和单元测试我的控制器.

现在,人们通常做出以下决定(这里是我的实际问题),摆脱了空控制器,并使用依赖注入定义什么方案中使用.

所以使用StructureMap我添加了以下注入规则:

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

在我的测试项目中,我正在使用不同的IContactsManagerDb实现.

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

但我的问题是,**我解决了什么问题,或者通过在这种特定情况下使用依赖注入简化了什么？

我现在没有看到任何实际用途,我理解如何但不是为什么？这有什么用？任何人都可以添加到这个项目,举个例子说明这个更实用和有用吗？

Answer 1

第一个示例不是单元可测试的,因此它不好,因为它在应用程序的不同层之间创建了强耦合,并使它们不再可重用.第二个例子叫做穷人依赖注入.这也在这里讨论.

穷人依赖注入有什么问题,代码不是自动记录.它没有向消费者说明其意图.消费者看到这个代码,他可以很容易地调用默认构造函数而不传递任何参数,而如果没有默认构造函数,它会立即清楚这个类绝对需要将一些契约传递给它的构造函数才能正常运行.并且真的不是要由班级来决定选择哪种具体实施方式.这取决于这个类的消费者.

Answer 2

依赖注入有三个主要原因:

• 它是一种解耦接口和实现的方法.
• 它有利于减少应用中锅炉板/工厂方法的数量.
• 它增加了包装的模块化.

作为示例 - 考虑单元测试,该测试需要访问定义为接口的类.在许多情况下,接口的单元测试必须调用该接口的实现 - 因此如果实现发生更改,单元测试也会发生变化.但是,使用DI,您可以在运行时将接口的实现"注入"到使用注入API的单元测试中 - 因此实现的更改只需要由注入框架处理,而不是由使用这些实现的单个类处理.

另一个例子是在Web世界中:考虑服务提供者和服务定义之间的耦合.如果特定组件需要访问服务 - 最好设计界面而不是该服务的特定实现.通过允许您通过引用注入框架动态添加依赖关系,Injection还支持此类设计.

因此,类别之间的各种耦合被移出工厂和个别类别,并且当具有良好的DI框架时,以统一,抽象,可重复使用且易于维护的方式处理.我见过的有关DI的最佳教程是关于Google的Guice教程,可在YouTube上找到.虽然这些与您的特定技术不同,但原则是相同的.