【发布时间】:2013-11-13 12:58:01
【问题描述】:
在blog post 上,人们可以阅读三个避免在控制器内部使用$this->getServiceLocator() 的原因。我认为这些原因不仅适用于控制器类,而且适用于实现ServiceLocatorAwareInterface 接口的任何类。
大多数时候被认为是一种反模式,使用ServiceLocatorAwareInterface注入依赖项?在什么情况下这种模式不能被认为是反模式?为什么?
谁能详细说明替代解决方案(我认为可能使用 Zend\DI)可能是什么?更具体地说,如何避免使用 ServiceLocatorAwareInterface Modules、Controllers 和 Bussiness/Domain 类。我很想了解有关 Zend\DI 及其解决方案的性能问题。
编辑
当我最后唯一能得到的是将“注入器代码”(以前的$this->getServiceLocator()->get($serviceName))移动到工厂而不解决测试问题时,是否值得为具有两个或三个依赖项的类定义工厂?当然,我也想测试我的工厂?还是没有?
我认为工厂必须保留在对象构建涉及复杂任务的情况下。在我看来,当类具有很少的依赖项和零逻辑(除了依赖项解决)时,工厂解决方案是对这个问题的过度杀伤。此外,通过这个解决方案,我将以更多的代码来测试(工厂)和更多的测试(测试工厂),同时尽量避免在测试实现中使用更少的代码。模拟服务定位器是一件容易的事,因为接口只有两个方法,模拟代码可以在所有测试用例之间共享。
如果我错了,请纠正我;)
Zend\DI 可能会有所帮助,但如果有人详细说明这种解决方案的具体细节,我将不胜感激。
编辑 2
几周前this Zend 网络研讨会(“ZF2 领域驱动设计简介”)使用了这种反模式(39:05)。我现在一直在徘徊,直到这真的是一种反模式;)
还有here 更多关于这个问题的信息。
福勒不得不说的是here
【问题讨论】:
标签: testing dependency-injection zend-framework2 inversion-of-control service-locator