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