除了测试之外,依赖注入如何比静态类/方法更好？

Question

除了可测试性之外,在静态类中使用DI(我不是在谈论DI框架或IoC)的最大优势是什么？特别是对于您知道服务不会被换出的应用程序.

在我们的一个c#应用程序中,我们的团队在Web Web GUI,服务层和存储库层中使用依赖注入,而不是使用静态方法.在过去,我们有POCO(业务实体对象),它们是由静态类创建,修改,传递和保存的.

例如,在过去我们可能写过:

CreditEntity creditObj = CreditEntityManager.GetCredit(customerId);
Decimal creditScore = CreditEntityManager.CalculateScore(creditObj);
return creditScore;

现在,使用DI,相同的代码将是:

//not shown, _creditService instantiation/injection in c-tors
CreditEntity creditObj = _creditService.GetCredit(customerId);
Decimal creditScore = _creditService.CalculateScore(creditObj);
return creditScore;

没有太大的不同,但现在我们有许多服务类具有更广泛的范围,这意味着我们应该将它们视为静态(即没有私有成员变量,除非它们用于定义进一步的依赖性).此外,如果这些方法中的任何一种利用资源(数据库/ Web服务/等),我们发现管理并发问题更加困难,除非我们删除依赖项并使用旧的静态或using(...)方法.

Answer 1

DI的问题可能是:CreditEntityManager实际上是集中知识如何找到CreditEntity和去哪里的自然场所CalculateScore？

我认为DI的理论是,参与的事情模块化应用X不一定知道如何连接带的东西Ÿ即使X需要ÿ.

在您的示例中,您将在找到服务提供程序并将其合并到数据对象后显示代码流.那时候,无论有没有DI它看起来都差不多,甚至可能完全相同,具体取决于编程语言,风格等.

关键是如何将这些不同的服务连接在一起.在DI中,可能第三方对象本质上是进行配置管理,但在此之后,代码应该大致相同.DI的目的不是为了改进以后的代码,而是为了尝试将问题的模块化特性与程序的模块化特性相匹配,以避免编辑逻辑上正确的模块和程序逻辑,但正在联系与错误的服务提供商.