zend-framework2 - Zend Framework 2 MVC 应用程序中的依赖管理

Question

因为 ServiceLocatorAwareInterface 可能是 removed from the AbstractController in ZF3 , 依赖项应该通过构造函数或 setter 方法传递。

考虑到这一点，考虑用户或站点 Controller 的用例，其中包含注册、激活帐户、登录、注销等操作。这至少需要一个 UserService 和 2 个表单。添加更多相关操作(远程身份验证、帐户链接等)，您最终会得到 4 或 5 个表单。

通过构造函数传递所有这些依赖关系充其量是困惑的，更重要的是，每个操作通常只需要一种形式。

您认为以下哪种技术更好，为什么？

为每个操作创建单独的 Controller ，以便每个 Controller 只需要一个表单(除了服务之外)。例如 RegistrationController、LoginController、LinkAccountController 等。

这样你最终会得到很多 Controller 。

在 Controller 的工厂中，根据请求的操作提供不同的形式。

Controller 的构造依赖于这个工厂，更具体地说是请求环境(路由等)。您可以直接构造 Controller (用于测试或其他)，但是您需要确保依赖关系可用并抛出异常如果不。

使用事件管理器，在需要表单时触发 Controller 中的事件，并让事件处理程序按需提供依赖。

描述了这种技术here .

然后，您的 Controller 将依赖于 EventManager 而不是 ServiceLocator，这可能不会好多少。

将 FormElementManager 传递给 Controller ​​，并从中请求表单。

最有可能不比SL本身更好。

直接在 Controller 内部构造表单。

这如何影响可测试性？

然后，同样的问题将适用于处理具有多个服务(而不是表单)的 Controller 。

其他？

也可以看看:

Passing forms vs raw input to service layer

Factory classes vs closures in Zend Framework 2

Answer 1

首先，ServiceLocator 不会被删除。也许只是 ServiceLocatorAwareInterface。

正如您所说，传递 FormElementManager 是一种解决方案，它确实比传递服务定位器更好。我个人使用越来越多的插件管理器，它们是解决这类问题的好方法。插件管理器与服务定位器不同，因为它只允许检索一种类型的对象(表单、水合器、输入过滤器......)。当然，由于父服务定位器被注入(inject)到插件管理器中，有些人会从插件管理器中检索服务定位器(这就是为什么我想在 ZF3 中删除插件管理器中的服务定位器，而是使用一个传递父定位器进行注入(inject)的特定工厂，尽管它会使工厂接口(interface)复杂一点:/...)。

通过将 Controller 拆分为更小的 Controller ，这应该使您的代码更清晰。

顺便说一句，您正在谈论身份验证，但是imo如果您正确地注入(inject)了身份验证服务(或将身份验证服务注入(inject)到用户服务或类似的东西中)，它会显着减少对 Controller 的依赖。