什么时候使用属性注入? [英] When to use property injection?
问题描述
- 什么时候应该使用属性注入?
- 如果在完全受控的情况下创建实例，我应该默认使用构造函数注入吗?
- 使用构造函数注入编写与容器无关的代码是否正确?
什么时候应该使用属性注入?
如果依赖项确实是可选的，当您有本地默认值，或者当您的对象图包含循环依赖项时，您应该使用属性注入.
属性注入然而会导致时间耦合以及在编写业务线时应用程序，您的依赖项永远不应该是可选的:您应该改为应用 空对象模式.>
您也不应该使用本地默认值，即:
<块引用>"在与使用者相同的程序集中定义的抽象的默认实现." [DIPP&P，第 4.2.2 节]
不应在业务线应用程序中使用本地默认值，因为它会使测试复杂化、隐藏依赖关系，并且容易忘记配置依赖关系.
对象图也不应该有循环依赖.这是您的应用程序设计中问题的指示.
<块引用>如果在完全受控的情况下创建实例，我应该默认使用构造函数注入吗?
是的.构造函数注入是最好的方法.它可以很容易地看到一个类有哪些依赖项，可以使依赖项成为必需，并防止时间耦合.
<块引用>使用构造函数注入编写与容器无关的代码是否正确?
这是正确的.构造函数注入允许你延迟决定使用哪个 DI 库，以及 完全使用 DI 库.
有关上述内容的更详细解释以及更多内容，请阅读依赖注入原则、实践和模式一书 (DIPP&P) 作者:Mark Seemann 和我自己.
属性注入的用处非常有限，以至于在编写本书时，Mark 和我甚至讨论了将属性注入标记为反模式的问题.最后，我们觉得我们无法做出像 Ambient Context，我们确实决定在那个版本中将其描述为反模式.Ambient Context 的情况非常清楚，而 Property Injection 的情况则更加混乱.但这就是为什么我们在属性注入部分 (4.4) 中添加了许多警告说明，因为我们强烈认为属性注入对于大多数情况来说并不是一个好的解决方案.
不过，Property Injection 一开始似乎解决了几个问题，例如 构造函数过度注入(其中一个构造函数包含许多依赖项).然而，构造函数过度注入几乎总是由设计缺陷引起的，例如:
- 班级有太多责任
- 缺乏自然集群
- 选择继承而非组合
- 通过基类而不是 Cross-Cutting Concerns"https://en.wikipedia.org/wiki/Decorator_pattern" rel="nofollow noreferrer">装饰器 或 拦截器
- When should I use property injection?
- Should I use by default constructor injection if instance creation in fully controlled?
- Am I right that using a constructor injection I write container-agnostic code?
When should I use property injection?
You should use property injection in case the dependency is truly optional, when you have a Local Default, or when your object graph contains a cyclic dependency.
Property Injection however causes Temporal Coupling and when writing Line of Business applications, your dependencies should never be optional: you should instead apply the Null Object pattern.
Neither should you use a Local Default, which is:
"A default implementation of an abstraction that's defined in the same assembly as the consumer." [DIPP&P, Section 4.2.2]
Local Defaults should not be used in Line of Business applications, because it complicates testing, hides the dependency, and makes it easy to forget to configure the dependency.
Neither should object graphs have cyclic dependencies. This is an indication of a problem in your application design.
Should I use by default constructor injection if instance creation in fully controlled?
Yes. Constructor injection is the best way. It makes it very easy to see which dependencies a class has, makes it possible to make dependencies required, and prevents Temporal Coupling.
Am I right that using a constructor injection I write container-agnostic code?
This is correct. Constructor injection allows you to delay the decision of which DI library to use, and whether at all you use a DI library.
For a more detailed explanation of the above, and much more, read the book Dependency Injection Principles, Practices, and Pattern (DIPP&P) by Mark Seemann and myself.
The usefulness of property injection is so limited, that while working on the book, Mark and I even discussed labeling Property Injection an anti-pattern. In the end we felt we couldn't make a case that was as strong as, for instance, Ambient Context, which we did decide to describe as an anti-pattern in that edition. The case for Ambient Context was crystal clear, while being much muddier for Property Injection. But this is why, however, we added many warning notes to the Property Injection section (4.4), because we feel strongly Property Injection is not a good solution for the majority of cases.
There are several problems, though, that Property Injection seems to solve at first, such as the problem of Constructor Over-Injection (where a constructor contains many dependencies). Constructor Over-Injection, however, is almost always caused by design deficits, such as:
- Class having too many responsibilities
- Lack of natural clusters
- Choosing inheritance over composition
- Application of Cross-Cutting Concerns through base classes instead of Decorators or Interceptors
这篇关于什么时候使用属性注入?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
