我知道如何使用依赖注入,但我认为没有实际的优势

Question

这是关于这个(注入依赖)

private readonly ICustomerService _customerService;
public Billing(ICustomerService customerService)
{
   _customerService = customerService;
}

与此相比(创建依赖关系)

private readonly ICustomerService _customerService;
public Billing()
{
   _customerService = new CustomerService();
}

后一个样本所以他们说是坏的因为......它违反了DI ...当然没有注入任何东西......但是如果DI不存在怎么办,那么客户服务是从Billing类手动创建的又是什么呢？我认为没有关于Service接口可交换性的实际优势.

我要求一个带有源代码的实际例子可能是一个单元测试或者显示一个实际的解决方案,为什么它更松散耦合.

有人热衷于展示他的DI肌肉,以及为什么它有实际的存在和应用权利？

UPDATE

所以人们都没有读完所有我会在这里写下我的短暂经历:

DI作为模式具有实际用途.通过不手动注入所有服务来跟踪DI(一个糟糕的人工DI工具,所以他们说...)使用像LightCore/Unity这样的DI框架,但一定要使用正确的工具来完成相应的工作.这是我没有;-)开发一个mvvm/wpf应用程序我有其他要求LightCore/Unity工具无法支持他们甚至是一个障碍.我的解决方案是使用MEFEDMVVM,我很高兴.现在我的服务在运行时自动注入而不是在启动时.:-)

Answer 1

了解如何理解为什么是非常不同的东西..

DI的最大好处之一是单元测试.在您的第二个示例中,如果不测试CustomerService(并且还测试链中的任何其他依赖项),则无法对Billing进行单元测试.在这种情况下,你不是单元测试,你是集成测试!如果你想要一个很好的理由来使用DI,你不需要再看单元测试的理由了.

Answer 2

想象一下它CustomerService连接到您的 CRM 系统和数据库。它创建一大堆网络连接来检索有关客户的数据，并且可能会从数据库中读取其他内容以在将数据返回到类Billing以在计算中使用之前进行扩充。

现在您想要进行单元测试Billing以确保其所做的计算是正确的（您不想发送错误的账单，对吗？）

Billing如果其构造函数与需要连接到真实 CRM 系统和数据库的类相关联，您将如何进行单元测试？将依赖项作为接口注入，轻松地允许您为测试提供模拟版本不是更好吗？

这就是 DI 有用的原因。