dependency-injection - 什么时候使用属性注入(inject)？

Question

什么时候应该使用属性注入？
如果实例创建处于完全受控状态，默认情况下应该使用构造函数注入吗？
我使用构造函数注入编写与容器无关的代码对吗？

Answer 1

什么时候应该使用属性注入？


如果依赖项确实是可选的，具有本地默认值或对象图包含循环依赖项，则应使用属性注入。

但是，属性注入会导致Temporal Coupling，并且在编写“业务线”应用程序时，您的依赖项永远不应是可选的：您应该应用Null Object pattern。

您也不应使用“本地默认值”，即：


“在与使用者相同的程序集中定义的抽象的默认实现。” [DIPP＆P，第4.2.2节]


本地默认值不应在业务应用程序中使用，因为它会使测试复杂化，隐藏依赖性，并使忘记配置依赖性变得容易。

对象图也不应该具有循环依赖性。这是您的应用程序设计中的indication of a problem。


如果实例创建处于完全受控状态，默认情况下应该使用构造函数注入吗？


是。构造函数注入是最好的方法。它使查看类具有哪些依赖关系变得非常容易，可以使所需的依赖关系成为可能，并且可以防止时间耦合。


我使用构造函数注入编写与容器无关的代码对吗？


这是对的。构造函数注入使您可以延迟使用哪个DI库以及whether at all you use a DI library的决策。

有关上述内容的更多详细说明，以及更多内容，请阅读Dependency Injection Principles, Practices, and Pattern和本人撰写的书Mark Seemann（DIPP＆P）。

属性注入的用途非常有限，以至于在撰写本书时，Mark和我甚至讨论了将属性注入标记为反模式。最后，我们觉得我们无法提供像Ambient Context这样强大的案例，我们确实决定将其描述为该版本中的反模式。环境语境的案例非常清晰，而对于属性注入来说则更为混乱。但是，这就是为什么我们在“属性注入”部分（4.4）中添加了许多警告说明的原因，因为对于大多数情况，我们强烈感到“属性注入”不是一个好的解决方案。

但是，属性注入似乎首先要解决一些问题，例如Constructor Over-Injection问题（其中构造函数包含许多依赖项）。但是，构造函数过度注入几乎总是由设计缺陷引起的，例如：


具有too many responsibilities的类
Lack of natural clusters
Choosing inheritance over composition
通过基类而不是Cross-Cutting Concerns或Decorators的Interceptors应用