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

【问题标题】：SoftwareArchitecture: Service Dependency - Inject Container or concret class软件架构：服务依赖——注入容器或具体类
【发布时间】：2014-02-14 14:33:38
【问题描述】：

假设以下服务类：

class A {}

class B {}

class C {}

现在Class A 依赖于Class B。所以我只注入Class B。在开发的后期，我的Class A 也需要Class C。（这可能会一直持续下去......）

注入依赖容器以便能够根据需要使用所有服务是否更好。或者通过只注入我需要的那些类来保持服务类很小？

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

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

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

【问题讨论】：

注入容器称为Service Locator，一种反模式。然而，最佳实践是意见，如果许多人有相同的意见并没有什么区别，它仍然是在征求意见。
我不同意这只是一个意见问题。有一些理由可以证明这里的答案是正确的，例如，请参阅我的答案。
在 Programmers.SE 上试一试，如果它是最佳实践的话。说“不要投票结束”并不是什么神奇的免疫咒语，可以防止人们关闭一个离题的问题。
@LegoStormtroopr 你知道“属于...”有一个关闭选项

标签： php symfony design-patterns dependency-injection software-design

【解决方案1】：

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

直接注入你需要的这些依赖。如果您注意到您的类中有很多依赖项，则应该提醒您该类做得太多（或有太多职责），您应该拆分它（或分开职责）。

【讨论】：

【解决方案2】：

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

原因：

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

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

【讨论】：

感谢您的回答。（@Opinion：我只是试图给出这个问题的理由。遗憾的是，这样的问题往往很快就结束了）

【解决方案3】：

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

恕我直言，注入整个依赖容器会给注入的类带来额外的开销。所以类应该只在需要时注入这些抽象。为了实现这一点，还需要从一开始就相应地设计类。

【讨论】：

感谢您的回答。 a b 和 c 类不是相对较低的类，它们位于应用程序的同一层。（但我知道你的意思）
我想稍微解释一下，当一个类有另一个类实例作为字段时，容器类称为higher，引用的类称为lower。而已！谢谢。