c# - 尝试应用良好的依赖注入(inject)实践时遇到的问题

Question

我已经在.NET中使用IoC（主要是Unity）和依赖注入了一段时间了，我真的很喜欢这种模式作为鼓励通过松散耦合创建软件类的方法，并且应该更容易进行测试隔离。

我通常尝试使用的方法是"Nikola's Five Laws of IoC"-特别是不注入容器本身，而仅使用构造函数注入，以便您可以从其构造函数签名中清楚地看到类的所有依赖项。 Nikola确实在这里有一个帐户，但是我不确定他是否仍在活动中。

无论如何，当我最终违反其他法律之一或通常以感觉或看起来不对的东西结束时，我不得不质疑我是否正在丢失某些东西，可以做得更好，还是根本不应该在某些情况下使用IoC。考虑到这一点，这里有一些例子，对于这些问题的任何指导或进一步的讨论，我将不胜感激：


具有过多依赖性的类。 （“任何具有超过3个依赖项的类都应受到SRP违规的质疑”）。我知道这个问题在依赖注入问题中经常出现，但是在阅读了这些问题之后，我仍然没有任何尤里卡时刻可以解决我的问题：


a）在大型应用程序中，我总是会发现需要3个依赖关系才可以访问基础结构（示例-日志记录，配置，持久性），然后才能获得该类完成其（希望有一项职责）工作所需的特定依赖关系。我知道可以将这种依赖关系组重构并包装到单个依赖项中的方法，但是我经常发现这只是其他几种服务的基础，而不是自己承担真正的责任。如果该类仍然具有单一职责，是否可以在此规则的上下文中忽略某些基础结构依赖性？
b）重构会增加这个问题。考虑分解一个已经变得很大的类的相当常见的任务-将功能的一个区域移到新类中，而第一类就依赖于它。假设第一类仍然需要以前具有的所有依赖关系，那么现在它具有一个额外的依赖关系。在这种情况下，我可能不介意此依赖性更加紧密地耦合在一起，但是让容器提供它仍然比较整洁（与使用new ...（）相对），即使没有新的依赖性也可以做到这一点它自己的界面。
c）在一个特定的示例中，我有一个类负责每隔几分钟运行一次系统中的各种不同功能。由于所有功能正确地属于不同区域，因此该类最终具有许多依赖关系，以便能够执行每个功能。我猜在这种情况下，应该考虑其他方法，可能涉及事件，但是到目前为止，我还没有尝试这样做，因为我想协调任务的运行顺序，并且在某些情况下应用涉及结果的逻辑方式。

一旦在应用程序中使用IoC，似乎我创建的几乎每个由另一个类使用的类最终都会在容器中注册和/或注入。这是预期的结果，还是某些课程与IoC无关？在代码中添加新内容的另一种选择看起来就像是代码气味，因为它随后紧密地结合在一起。这也与上面的1b有关。
我在应用程序启动时完成了所有容器初始化，为系统中的每个接口注册类型。有些是故意的单实例生命周期，其中有些每次解决时都可以是新实例。但是，由于后者是前者的依赖项，因此在实践中它们也成为单个实例，因为它们在单个实例的构造时仅被解析一次。在许多情况下，这无关紧要，但是在某些情况下，我确实每次执行操作时都想要一个不同的实例，因此我不得不要么要么无法使用内置的容器功能，要么而是使用工厂依赖项，以便我可以强制这种行为，或者ii）在容器中传递，以便每次都可以解决。这两种方法在尼古拉的指导中都不适用，但我认为i）是两种弊端中的较小者，在某些情况下，我确实会使用它。

Answer 1

在大型应用程序中，我总是发现我仅需要3个依赖关系即可访问基础结构（示例-日志记录，配置，持久性）


imho基础架构不是依赖项。使用servicelocator获取记录器（private ILogger _logger = LogManager.GetLogger()）时没有问题。

但是，在我看来，持久性不是基础架构。这是一个依赖关系。将您的课程分成更小的部分。


  重构会增加这个问题。


当然。在成功重构所有类之前，您将获得更多的依赖关系。只需挂在那里，然后继续进行重构即可。

不要在单独的项目（分离的接口模式）中创建接口，而不是向类添加依赖项。


  在一个特定的示例中，我有一个类负责每隔几分钟运行一次系统中的各种不同功能。由于所有功能正确地属于不同区域，因此该类最终具有许多依赖关系，以便能够执行每个功能。


那么您将采用错误的方法。任务运行者不应该依赖于应该运行的所有任务，反之亦然。所有任务都应在运行程序中注册。


  一旦我在应用程序中使用IoC，似乎我创建的几乎每个由另一个类使用的类最终都会在容器中注册和/或注入。*


我在容器中注册了除业务对象，DTO等之外的所有内容。


  我在应用程序启动时完成了所有容器初始化，为系统中的每个接口注册类型。有些是故意的单实例生命周期，其中有些每次解决时都可以是新实例。但是，由于后者是前者的依赖项，因此在实践中它们也成为单个实例，因为它们在单个实例的构造时仅被解析一次。


如果可以避免，请不要混在一起。或不要接受短暂的依赖关系。在这种情况下，您可以使用简单的消息传递解决方案来更新单个实例。

您可能需要阅读我的guidelines。