4

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

大多数时候被认为是一种反模式，使用ServiceLocatorAwareInterface? 在什么情况下这种模式不能被认为是反模式，为什么？

任何人都可以详细说明替代解决方案（我认为可能使用Zend\DI ）吗？更具体地说，如何避免使用ServiceLocatorAwareInterface Modules、Controllers和Business/Domain类。我对 Zend\DI 及其解决方案的性能问题很感兴趣。

编辑

值得为具有两个或三个依赖项的类定义工厂，而我最后唯一能得到的是将“注入器代码”（前者$this->getServiceLocator()->get($serviceName)）移动到工厂而不解决测试问题？当然，我也想测试我的工厂？或者没有？

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

如果我错了，请纠正我；）

Zend\DI可以提供帮助，但如果有人详细说明这种解决方案的细节，我会很高兴。

编辑 2

几周前，这个Zend 网络研讨会（“使用 ZF2 介绍域驱动设计”）使用了这种反模式 (39:05)。我现在一直在徘徊，直到这真的是一种反模式；）

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

福勒要说的就在这里

4

2 回答 2

2

解决这个问题其实很容易，通过构造函数注入你的依赖。这消除了许多会在大型应用程序中引起问题的魔法。

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

于 2013-11-02T18:05:37.963 回答
0

如果您使用 ServiceLocatorAwareInterface，最后一个 ZF2 版本（zendframework/zend-mvc 2.7.0 和 +）会引发Depracated警告，并且 ZF 文档（在撰写此答案时）不清楚并且仍在使用此接口。ZF“大师”不谈论更新文档。如果您不是 ZF2 专家（在撰写此答案时），则很难找到具体的示例。

但幸运的是，Rob Allen 几年前写了一篇文章来解释如何删除 SL 依赖并将其注入您的控制器：https ://akrabat.com/injecting-dependencies-into-your-zf2-controllers/这解决了问题. 希望这会有所帮助！

于 2016-03-03T10:49:48.003 回答