如果依赖项仅用于单个方法，我应该注入它还是使用服务位置？

Question

我对依赖注入有点新意，在工作时遇到了问题。

让我们说我有一个班级'员工'有一种方法，这种方法说'推广'在极端情况下也有条件地被称为“推广”。

'Promote'方法使用'ValueAddition'的对象，现在最好的做法是通过构造函数和用户全局对象注入此对象，还是应该解决方法本身的依赖？

什么是推荐的最佳做法？或任何关于解决依赖的生命时间的指针都会有所帮助。

Answer 1

通常，您应始终注意注入依赖项而不是使用服务位置（即直接从控制容器的反转中解析依赖项）。 There's a great, pretty well known blog article here called "Service Locator is an Anti-Pattern" that can help clarify the reasons.

您可能会在展开时遇到其他问题，这些问题似乎指向您使用服务位置。一般来说，你真的应该围绕这些问题进行设计，而不是回到服务地点。

• 我只需要一个方法中的对象。考虑将方法的功能移动到其他对象。例如，也许Promote()方法应该在IEmployeePromoter上，你解决它，它需要特殊的对象。然后你打电话给Promote(Employee)并传入员工，而不是改变Employee的依赖关系。有时您的控制容器反转将有一种方法来生成工厂（如Func<T>或Lazy<T>），以帮助您推迟解决，直到您真正需要它。
• 我有太多的依赖项。通常这意味着你的对象做得太多了。 single responsibility principle可以帮助您将对象重构为更易于管理的大小。较小的对象通常需要较少的依​​赖项，因为它们需要管理的问题要少得多。

有关依赖注入模式的大量文档和书籍。在未应用于特定框架（甚至语言）时，将搜索范围扩大到查看一般模式和实践可能会很好，它可以帮助您了解自己代码中的最佳实践。