在参加了 ZendCon 2012 之后，我看到了 ZF2 中的许多类是如何实现 DI 并通过构造函数将它们的依赖项传递给它们的。ZF2 有一个服务管理器可以帮助解决这个问题。我正在尝试学习如何实现这一点并学习其最佳实践。
然后......我加载了ZfcUser模块并看到用户服务并没有完全遵循这种模式，实际上它隐藏了它的依赖关系在一堆延迟加载 getter 后面。现在，这个模块最初是由 Evan Coury 编写的，他是 ZF2 中整个模块系统背后的大脑，所以我知道这个特定模块写得很好，或者至少遵循了建议的 zf2 最佳实践。
我的问题是，为什么这个类将其依赖项隐藏在 getter 后面并实际上从服务管理器中获取它们（在这种情况下，它看起来就像一个注册表），而不是在构造函数中明确定义它们？
这实际上是不是违背了 DI 明确依赖关系的原则？
我从 Zend Framework 邮件列表上的 Artur Bodera 那里得到了这个问题的答案：
这并不反对。它仍然是一种“控制反转”的做事方式，这是一件好事。
ZF2 DI 在 2011 年底一直在积极开发中，并在贡献者中获得了很多关注。但在某些时候，性能和配置文件的复杂性成为了一个问题。这就是为什么提出了ServiceManager的想法。
直到 beta1 (AFAIR) 之前，几乎所有内容都在 DI 中定义，并且配置文件非常庞大。应用程序很慢，内存使用量很大，与 ZF1 Application_Service 或类似的相比，复杂性实际上有所增加。有一些关于如何进一步优化 DI 的想法，但一群贡献者提出了另一个想法：SM。
ServiceManager 允许以更明确的方式构建服务。例如，您可以只使用带有几个“new This”、“new最后”和“return $service”。
没有针对 SM 或 DI 的严格政策或建议。两者都可以，都有优点和缺点。这是您的选择，您将使用它。两者都被 Zend\Mvc 识别，并将从您的应用程序配置中读取。
至于模块 - 每个模块的作者决定使用哪种方法。再一次 - 两者都是处理依赖关系和自动构造实例的有效方法。Evan 在这个例子中选择了 SM 工厂。
希望埃文能来解释自己，因为他最喜欢能做得更好。我的猜测是，这仅仅是因为每次调用 User-Service 时都加载所有依赖项，只会产生过多的开销。因此延迟加载。很可能这就是它的全部。