这是关于这个(注入依赖)
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,我很高兴.现在我的服务在运行时自动注入而不是在启动时.:-)
