c# – 依赖注入有什么大的改进?

前端之家收集整理的这篇文章主要介绍了c# – 依赖注入有什么大的改进?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
目前我正在尝试更好的了解依赖注入,我正在使用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>();

但是我的问题是,**在这个具体情况下,我使用依赖注入解决了什么问题或者简化了什么?

我现在看不到任何实际的使用,我明白了,但是不知道为什么?这有什么用?任何人都可以添加这个项目,可以举一个例子,这更实际和有用吗?

解决方法

第一个例子不是单元可测试的,所以它不是很好,因为它在应用程序的不同层之间创建了一个强大的耦合,并使它们不再可重用.第二个例子叫做 poor man dependency injection.另外还有 here.

穷人依赖注入有什么问题是代码不是自动记录的.它并不表示其对消费者的意图.消费者看到这个代码,他可以轻松地调用默认构造函数,而不传递任何参数,而如果没有默认构造函数,那么它将立即清楚,该类绝对需要将一些合同传递给其构造函数才能正常运行.确实选择哪个具体的实施方式真的不是上课.这取决于这个阶层的消费者.

原文链接:https://www.f2er.com/csharp/96002.html

猜你在找的C#相关文章