在此blog post可以阅读三个避免 $this->getServiceLocator() 内部 Controller 的原因。我认为这些原因不仅适用于 Controller 类，而且适用于实现 ServiceLocatorAwareInterface 接口(interface)的任何类。
大多数时候被认为是反模式使用 ServiceLocatorAwareInterface 注入(inject)依赖项？在什么情况下不能将此模式视为反模式？为什么？
任何人都可以详细说明替代解决方案(我认为可能使用 Zend\DI)吗？更具体地说，如何避免使用 ServiceLocatorAwareInterface Modules、Controllers 和 Bussiness/Domain 类。我很想了解 Zend\DI 及其解决方案的性能问题。
编辑
值得为具有两个或三个依赖项的类定义工厂，而最后我唯一能得到的就是移动“注入(inject)器代码”(以前的 $this->getServiceLocator()->get($serviceName)) 到工厂而不解决测试问题？当然我也想测试我的工厂？还是没有？
我认为工厂必须保留给对象构建涉及复杂任务的情况。在我看来，当类几乎没有依赖关系和零逻辑(除了依赖关系解决)工厂解决方案是这个问题的过度杀伤力。此外，通过这个解决方案，我将以更多代码测试(工厂)和更多测试(测试工厂)结束，同时尽量避免在测试实现中使用更少的代码。模拟服务定位器是一件容易的事情，因为接口(interface)只有两个方法，模拟代码可以在所有测试用例之间共享。
如果我错了，请纠正我；)
Zend\DI 可以提供帮助，但如果有人详细说明这种解决方案的细节，我将不胜感激。
编辑 2
几周前this Zend 网络研讨会(“ZF2 域驱动设计简介”)使用了这种反模式 (39:05)。我现在正在徘徊，直到这真的是一个反模式；)
和here有关此问题的更多信息。
福勒要说的是 here
最佳答案
解决这个问题其实很简单，通过构造函数注入(inject)你的依赖。这消除了很多会在大型应用程序中引起问题的魔力。
所以这意味着您需要创建工厂而不是使用可调用类。 如此处的文档所示:http://framework.zend.com/manual/2.2/en/modules/zend.service-manager.intro.html
关于testing - ZF2。替代让 AbstractController(或其他类)实现 ServiceLocatorAwareInterface？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19741779/