ZfcUser \ Service \用户依赖注入模式说明

Question

在参加ZendCon 2012之后，我看到了ZF2中很多实现DI并通过构造函数传递给它们的依赖关系的类。 ZF2有一个服务管理器，可以帮助解决这个问题。我正在努力学习如何实现这一点并学习它的最佳实践。

然后......我加载了ZfcUser模块，发现User Service并没有完全遵循这种模式，事实上它隐藏了一堆延迟加载getter背后的依赖关系。现在，这个模块最初是由Evan Coury编写的，他是ZF2中整个Module系统的大脑，因此我知道这个特定的模块编写得很好，或者至少遵循建议的zf2最佳实践。

我的问题是，为什么这个类隐藏了getter背后的依赖关系并实际从服务管理器中获取（在这种情况下，它看起来就像是一个注册表）而不是在构造函数中明确定义它们？

这实际上是否违反了使依赖关系明确的DI原则？

Answer 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工厂。

Answer 2

希望Evan会来解释自己，因为他最喜欢能够做得更好。我的猜测是，这只是因为每次调用User-Service时加载所有依赖项，只会产生方式过多的开销。因此懒加载。最有可能的就是它。