c# – 我知道如何使用依赖注入,但我认为没有实际的优势
这是关于这个(注入依赖)
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,我很高兴.现在我的服务在运行时自动注入而不是在启动时.:-) 解决方法
想象一下,CustomerService连接到您的CRM系统和数据库.它创建了一大堆网络连接来检索有关客户的数据,并可能从数据库中读取其他内容以在将数据返回到Billing类以在其计算中使用之前对其进行扩充.
现在你想进行单元测试计费以确保它正在进行的计算是正确的(你不想发错账单吗?) 如果Billing的构造函数绑定到需要连接到真实CRM系统和数据库的类,那么您将如何对Billing进行单元测试?将依赖项作为接口注入是不是更好,可以轻松地为您的测试提供模拟版本? 这就是DI很有用的原因. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |