由于 ServiceLocatorAwareInterface 可能是从 ZF3 中的 AbstractController 中删除，依赖项应该通过构造函数或 setter 方法传递。
考虑到这一点，请考虑用户或站点控制器的用例，包括注册、激活帐户、登录、注销等操作。这至少需要一个 UserService 和 2 个表单。添加更多相关操作（远程身份验证、帐户链接等），最终会得到 4 或 5 个表单。
通过构造函数传递所有这些依赖项充其量也是混乱的，更重要的是，每个操作通常只需要 1 个表单。
您认为以下哪一项技术更好，为什么？
-
为每个操作创建单独的控制器，以便每个控制器只需要一个表单（除了服务之外）。例如RegistrationController、LoginController、LinkAccountController等。
-
在控制器的工厂中，根据请求的操作提供不同的表格。
- 控制器的构造依赖于这个工厂，更具体地说是请求环境（路由等）。您可以直接构造控制器（用于测试或其他），但是您需要确保依赖项可用并抛出异常如果不。
-
使用事件管理器，在需要表单时在控制器中触发事件，并让事件处理程序根据需要提供依赖项。
- 该技术被描述为here.
- 然后，您的控制器将依赖于 EventManager，而不是 ServiceLocator，这可能也好不了多少。
-
将 FormElementManager 传递给控制器，并从中请求表单。
-
直接在控制器内构造表单。
- 这如何影响可测试性？
- 同样的问题也适用于处理具有多个服务（而不是表单）的控制器。
Other?
也可以看看：
- 将表单传递给服务层与原始输入
- Zend Framework 2 中的工厂类与闭包
首先，ServiceLocator 不会被删除。也许只是 ServiceLocatorAwareInterface。
正如您所说，传递 FormElementManager 是一种解决方案，它确实比传递服务定位器更好。我个人正在使用越来越多的插件管理器，它们是解决此类问题的好方法。插件管理器与服务定位器不同，因为它只允许检索一种类型的对象（表单、水合器、输入过滤器...）。当然，当父服务定位器被注入到插件管理器中时，有些人会采取从插件管理器检索服务定位器的技巧（这就是为什么我想在 ZF3 中删除插件管理器中的服务定位器，而是使用一个传递父定位器进行注入的特定工厂，尽管这会使工厂接口变得有点复杂：/...）。
通过将控制器拆分为更小的控制器，这应该会使您的代码更清晰。
顺便说一句，您正在谈论身份验证，但在我看来，如果您正确注入身份验证服务（或将身份验证服务注入用户服务或类似的东西），它会显着减少对控制器的依赖性。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
