你什么时候使用依赖注入？

Question

我最近一直在使用StructureMap并且彻底享受了这种体验.但是,我可以看到如何通过连接所有内容轻松地将其带走,并最终获得将大量接口引入其构造函数的类.尽管在使用依赖注入框架时这确实不是一个大问题,但它仍然认为某些属性实际上不需要为了连接它们而需要接口.

你在哪里画出界面的界限而不仅仅是在课堂上添加一个属性？

Answer 1

依赖注入的主要问题是,虽然它给出了松散耦合架构的外观,但事实并非如此.

你真正在做的是将这种耦合从编译时移到运行时,但是如果A类需要一些接口B工作,仍然需要提供实现接口B的类的实例.

依赖注入仅应用于需要动态更改的应用程序部分,而无需重新编译基本代码.

使用我看到对控制反转模式有用的东西:

• 插件架构.因此,通过制作正确的入口点,您可以定义必须提供的服务的合同.
• 类似工作流的架构.您可以在其中连接多个组件,动态地将组件的输出连接到另一个组件的输入.
• 每客户端应用程序.假设您拥有各种客户,这些客户支付项目的一系列"功能".通过使用依赖注入,您可以轻松提供核心组件和一些"添加"组件,这些组件仅提供客户端支付的功能.
• 翻译.虽然通常不会出于翻译目的,但您可以根据应用程序的需要"注入"不同的语言文件.这包括RTL或LTR用户界面.

Answer 2

想想你的设计.DI允许您通过配置更改来更改代码的功能.它还允许您打破类之间的依赖关系,以便您可以更轻松地隔离和测试对象.你必须确定它有意义的地方和不合适的地方.没有轻拍的答案.

一个好的经验法则是,如果它太难以测试,那么你就会遇到一些单一责任和静态依赖的问题.将执行单个函数的代码隔离到类中,并通过提取接口并使用DI框架在运行时注入正确的实例来中断静态依赖性.通过这样做,您可以轻松地分别测试这两个部分.

Answer 3

依赖注入仅应用于需要动态更改的应用程序部分,而无需重新编译基本代码

DI应该用于将代码与外部资源(数据库,Web服务,xml文件,插件体系结构)隔离开来.如果您正在测试数据库上的DEPEND组件,那么在许多公司中,在代码中测试逻辑所需的时间几乎是令人望而却步的.

在大多数应用程序中,数据库不会动态更改(尽管可能),但一般来说,将应用程序绑定到特定外部资源几乎总是好的做法.涉及改变资源的数量应该很低(数据访问类应该很少在其方法中具有高于一的圈复杂度).