dependency-injection - DI : How much to inject?

Question

我正在编写我的第二个现实生活应用程序，它使用 DI。总的来说，我认为它已经让一个更好的设计。但是有一些代码异味，我不知道如何解决。

我更喜欢使用构造函数注入(inject)，并且经常观察到我需要在构造函数中注入(inject)大约 5 个或更多对象。好像太多了，可能是设计问题，没有把SRP弄对。但我认为我对 DI 的使用也应该受到指责。

我正在寻找“最佳实践”或“经验法则”，一般来说，我似乎注入(inject)了所有不在 .Net 框架中的东西，是不是有点过头了？

首先，这里有两个我注入(inject)但不确定的对象示例。

真正的单例对象，例如应用程序配置或那些小的 util 类，你会注入(inject)它们吗？
它们似乎经常被注入(inject)，注入(inject)它们的唯一原因似乎是允许更改测试值，但 Ayende 似乎以另一种方式解决了问题:http://ayende.com/Blog/archive/2008/07/07/Dealing-with-time-in-tests.aspx .

几乎每个对象都使用的常见对象(例如日志记录)是否应该注入(inject)？

Answer 1

我经常使用的经验法则是，我注入(inject)了妨碍正确编写单元测试的东西。这样做时，您有时最终会抽象出 BCL 类(例如 DateTime.Now、File 等)，有时还会抽象出您自己的东西。注入(inject)的好东西是服务(例如 ICustomerService、ICustomerUnitOfWorkFactory 或 ICustomerRepository)。不要注入(inject)实体、DTO 和消息之类的东西。

然而，注入(inject)对象还有其他原因，例如能够在以后替换模块(例如切换实现以进行验证、UI 或 O/RM)，以允许团队内部或跨团队进行并行开发，以及降低维护.

I prefer to use constructor injection and have often observed that I need about 5 or more objects to be injected in the constructor.

正如您自己已经注意到的，有许多依赖关系可能是由于不遵守 SRP 造成的。 .但是，您可以做的是将具有逻辑的常见依赖项分组到聚合服务中，并将其注入(inject)消费者。另见 Mark Seemann 关于 Aggregate Services 的文章.

Objects that are true singletons like application configuration or those small util classes, do you inject them?

我个人不喜欢 Ayende 提出的方式。这是 Ambient Context ，它是 service locator 的一种特定类型构造。这样做会隐藏依赖关系，因为类可以调用该静态类而无需注入(inject)它。显式注入(inject)它可以更清楚地表明您需要对时间进行单元测试。除此之外，很难为 MSTest 等倾向于并行运行测试的框架编写测试。如果没有任何对策，它会使您的测试非常不可靠。更好的解决方案 - 对于 DateTime.Now示例- 是有一个 IClock接口(interface)，建议 here .如您所见，该答案的得分远高于 Ayende 方法，这在同一个 SO 问题中显示。

Common objects such as logging, that are used in almost every object, should they be injected?

我将它们注入(inject)我的代码中，因为这使依赖关系变得清晰。但是请注意，在我的代码中，我仍然几乎不需要注入(inject)记录器。仔细考虑您要记录的每一行，这并不是真正的失败(或应该放在其他地方的横切关注点)。当我没有预料到的事情发生时，我通常会抛出异常。它使我能够快速找到错误。或者换句话说:不要过滤，但要快速失败。请问问自己:“ Do I log too much?”

我希望这有帮助。