ZF2。替代AbstractController (或其他类)实现ServiceLocatorAwareInterface？

Question

在这个博客帖子中，人们可以读到避免控制器内部$this->getServiceLocator()的三个原因。我认为这些原因不仅适用于控制器类，而且适用于实现ServiceLocatorAwareInterface接口的任何类。

大多数情况下，使用ServiceLocatorAwareInterface注入的依赖关系被认为是反模式获取吗？在什么情况下，这种模式不能被认为是反模式，为什么？

有人能详细说明另一种解决方案(我认为可能使用Zend\DI )吗？更具体地说，如何避免使用ServiceLocatorAwareInterface模块、控制器和业务/域类。我很感兴趣地了解Zend\DI及其解决方案的性能问题。

编辑

当我最终只需要将“注入器代码”(前$this->getServiceLocator()->get($serviceName))移到工厂而根本不解决测试问题时，是否值得为具有两个或三个依赖项的类定义工厂呢？当然，我也想测试我的工厂？还是没有？

我认为工厂必须保留在对象构建涉及复杂任务的情况下。在我看来，当类几乎没有依赖和零逻辑(除了依赖解决之外)工厂解决方案是这个问题的过头。此外，使用此解决方案，我将以更多的代码来测试(工厂)和更多的测试(测试工厂)结束，同时尝试在测试实现中避免更少的代码。模拟服务定位器是一件容易的事情，因为接口只有两种方法，并且模拟代码可以在所有测试用例之间共享。

如果我错了，请纠正我;)

Zend\DI可能会有所帮助，但如果有人详细介绍这种解决方案的具体细节，我会很优雅。

编辑2

几周前，这 Zend (“ZF2领域驱动设计简介”)使用了这种反模式(39:05)。我现在在徘徊，直到这是一个真正的反模式;)

和这里有关这个问题的更多信息。

福勒要说的是这里

Answer 1

实际上很容易解决这个问题，通过构造函数注入您的依赖项。这消除了在更大的应用程序中导致问题的许多魔力。

因此，这意味着您需要创建工厂，而不是使用可调用的类。如这里的文档所示：http://framework.zend.com/manual/2.2/en/modules/zend.service-manager.intro.html

Answer 2

上一个ZF2版本(zendframework/zend-mvv2.7.0和+)如果使用ServiceLocatorAwareInterface，就会抛出Depracated警告，而throws (在编写这个答案时)并不清楚，并且仍然使用这个接口。ZF‘古鲁’不谈论更新文档。如果你不是ZF2专家(在撰写这个答案的时候)，很难找到一个具体的例子。

但是幸运的是，Rob几年前写了一篇文章来解释如何删除SL依赖并将它注入到控制器中：https://akrabat.com/injecting-dependencies-into-your-zf2-controllers/ --它解决了问题。希望这能帮上忙！