我对Manager和Service类名称后缀感到有些困惑。
据我了解差异，Managers负责处理（创建，检索，删除......）某些类型的实体。例如，ModuleManager负责加载和返回Modules。在这种情况下，您做关心实际的实体Module。
但是，Services是提供执行cetain类型的流程逻辑的接口的类。例如，LogService将给定的日志消息发送到定义的日志编写器。你不关心它的去向和做什么，你只想让管理员了解刚刚发生的事情。
现在，ZF2提供了一个ServiceManager，它创建并返回给定Service的实例。我不小心习惯于创建Managers并向factory提供ServiceManager，以便您可以使用Manager中的$this->getServiceLocator()->get('managerName');访问Controller上下文，以保持控制器微小和可测试类中的真实逻辑。这是让我感到困惑的部分，因为很明显，建议不要使用Managers来检索ServiceLocator。 但是：我不是唯一这样做的人：Doctrine ORM模块就是另一个例子：它将EntityManager注册为doctrine.entitymanager.orm_default Service 默认情况下。
我是否认为Services和Managers之间存在真正的区别？甚至还有区别吗？ Managers甚至可能从概念中的Services继承而来吗？
答案 0 :(得分：39)
我会尝试为您分解ZF2中的经理和服务。
不幸的是，“经理”这个词在引用类时非常模糊，在ZF2中，与使用该词的方式有些不一致。因此，对于ZF2中的“经理”来说，确实没有权威的定义。目前，ZF2中的“经理人”最好像这样分解：
Zend\ServiceManager\ServiceManager的实例。可以有多个ServiceManager实例 - 默认情况下，只有“main”服务管理器，它配置了'services'配置键或Module的getServiceConfig（）方法返回的数组。Zend\ServiceManager\PluginManager扩展了Zend\ServiceManager\ServiceManager一些专门的功能。它们遍布框架中的许多组件，并提供先前已知的（在早期版本的ZF2中）作为插件加载器/代理的功能。这些插件管理器可以初始化view helpers，controller plugins和controllers themselves等内容。Zend\ModuleManager\ModuleManager和Zend\Session\SessionManager等内容。这些与ServiceManager无关，但恰好将'Manager'作为其名称的后缀。我认为您可能会在尝试为术语（经理）分配一个未定义任何特定定义的术语时感到困惑。作为Zend\ModuleManager的作者，我可以告诉您，我最初将组件开发为Zend\Module（我真的不喜欢Manager作为后缀）。在one of our weekly IRC meetings中决定Zend\Module是模棱两可的，用'经理'后缀它会以某种方式解决这种模糊性。显然我在这个问题上被投了票。我的观点是，Zend\ModuleManager并未按照任何定义发展为任何“经理人”的规范。
在ZF2中，关于Zend\ServiceManager，'services'只是对象（技术上也可以是数组）。可以将ServiceManager组件视为应用程序可能需要的各种“服务”（对象）的简单键值注册表。这些“服务”通常是配置的邮件程序，记录器，数据库适配器，应用程序配置等。当然，ServiceManager不是只是一个简单的注册表，其主要功能是推迟实例化服务（及其依赖关系），直到实际需要它们为止;又懒加载）;我写了blog post which explains the various features of the ServiceManager in depth。
我不小心习惯了创建Managers并向ServiceManager提供工厂，以便您可以使用$ this-＆gt; getServiceLocator（） - ＆gt; get（'managerName）
访问管理器
我认为在这种情况下，您可能会将“经理”这个词与“服务”混为一谈。使用ServiceManager注册的内容可以简称为“服务”。这可能令人困惑，因为您确实可以将某种“经理”注册为服务。例如，您可以拥有一个“会话”服务，该服务是Zend\Session\SessionManager的实例。随之而来的是混乱，因为术语“服务”通常指的是构成service layer一部分的类。
所以，不幸的是，是的，ZF2中的术语可能有点模糊，但是一旦你理解了几个相对简单的核心概念，这个伟大的设计确实开辟了一些惊人的灵活性，在我看来，这是大多数人无法比拟的。现有的其他框架。
希望这有帮助。