软件架构：服务依赖 - 注入容器或具体类

Question

假设以下服务类：

class A {}

class B {}

class C {}

现在Class A依赖于Class B。所以我只是注入Class B。 在开发的后期，Class A也需要Class C。 （这可以继续......）

注入Dependency Container以便能够根据需要使用所有服务更好。或者只注入我需要的那些类来保持服务类的小？

这里是最好的做法，为什么？

目前我倾向于注入我需要的每个依赖服务，主要是为了在一个地方看到依赖（标题中的DI注释）。

  

请不要以“基于意见为基础”关闭这个问题是最好的   实践，这必须是一个意见，但当大多数用户拥有   同样的观点是最佳实践。

Answer 1

我建议不要注入整个服务容器。如果你这样做，类依赖会变得模糊（例如，你必须通过整个类代码来查看这个类需要什么依赖项），这可能会导致一团糟。

直接注入您需要的依赖项。如果你注意到你的课程中存在很多依赖关系，那么应该警告你这个课程做得太多（或者责任太多），你应该将它分开（或者分开职责）。

Answer 2

不要注射容器。这是服务定位器模式，通常将其视为反模式。

原因：

• 注入容器会将代码耦合到容器中，这很糟糕，因为如果要更改所使用的容器，则需要更改许多类
• 它还隐藏了您的类所需的依赖项：依赖项不再是显式的。假设我想使用你的类，我如何知道我需要在容器中设置哪些依赖项才能让你的类工作？
• 如果您注入容器会发生什么，然后您的类获得依赖项但依赖项不存在：exception

这不仅仅是一种意见，有充分的理由证明依赖注入服务位置。

Answer 3

注入具体classes与依赖性倒置原则（DIP）相矛盾。在你的情况下，class A（相对较高的类）不应该依赖class B（相对较低的类）;两者都应该取决于抽象。因此，class B继承或实现的抽象类或接口应注入class A。 class A和class C也是如此。

恕我直言，注入整个Dependency Container会给注入的类带来额外的开销。因此，只有在需要时才应该向类注入这些抽象。为了实现这一目标，还需要从一开始就相应地设计课程。