依赖注入框架值得额外的间接层吗？

您是否发现依赖注入框架使代码更难以遵循？间接是否超过了利益？

是的,您的代码变得更加分离并且更加可测试.当您进行大量测试并且每个测试需要一个繁重的对象(如数据库层)时,这尤其会变得很方便.

如果使用依赖注入,则可以简单地创建所谓的"模拟"对象或存根,并使用它们来使测试运行得更快并且副作用更少(数据库状态).

确实,您无法通过查看代码直接查看使用的实现.您将看到对该界面的引用.一个好的IDE可能具有查看特定接口的所有实现的功能,因此请使用它.

对于非平凡的"企业"应用程序,是的,这是值得的.在DI框架之前,每个商店都在其他项目使用的某个内部库中实现了自己的花哨"ServiceLocator"类.所以你在整个代码库中都有这样的东西.

这些调用表示对象需要发现/配置自己的依赖项.DI框架消除了所有代码,因此您的对象变得更简单,因此更容易测试.

现在,由此可见如果对象的依赖关系中没有很多可变性,则间接值(集中式配置)对您来说就不那么重要了.

有关DI与ServiceLocator对比的更多详细信息,请参阅Fowler的控制容器反转和依赖注入模式

我发现自定义静态HashTable工厂可以很好地解耦我的依赖项并满足我的需求.我已经尝试了几次使用一个完整的IOC容器,每次我对我的团队其他成员必须忍受的学习曲线(和所有配置)感到吃惊......以及所有这些或者我的香草没有添加功能.

因此,我认为依赖注入的更大问题不在于模式本身,而在于它目前在开发人员社区中生成的Fad.这听起来很酷,所以使用它的压力很大,即使工程不是由相应的要求驱动的.

我们倾向于拿一把大枪给蚊子,因为枪看起来很酷.

P