20

我对ManagerandService类名后缀有点困惑。

据我了解的区别，Managers负责处理（创建，检索，删除，...）某些类型的实体。例如，ModuleManager负责加载和返回Modules。在这种情况下，您确实关心实际的实体Module.

但是，Services是提供接口以执行某些类型的流程逻辑的类。例如，aLogService将给定的日志消息发送到定义的日志写入器。您不关心它的去向和作用，您只希望管理员了解刚刚发生的事情。

现在，ZF2 提供了一个ServiceManager创建和返回给定实例的Service. 我不小心习惯了创建Managers并提供一个factorytoServiceManager以便您可以在上下文中访问Managerusing以保持控制器的微小和可测试类中的真实逻辑。这是现在让我感到困惑的部分，因为显然，不建议使用. 但是：我不是唯一这样做的人：该模块是另一个例子：它默认注册为 a 。$this->getServiceLocator()->get('managerName');ControllerManagersServiceLocatorDoctrine ORMEntityManagerdoctrine.entitymanager.orm_default Service

我得到了Services和Managers错误之间的真正区别吗？甚至有区别吗？Managers甚至可能从Services概念中继承？

4

1 回答 1

39

我将尝试为您分解 ZF2 中的管理器和服务。

经理人

不幸的是，提到类的“经理”这个词非常模棱两可，在 ZF2 中，这个词的使用方式有些不一致。因此，对于 ZF2 中的“经理”是什么，确实没有权威的定义。目前，ZF2 中的“经理”最好这样分解：

  • ServiceManager — 的一个实例Zend\ServiceManager\ServiceManager。可以有多个 ServiceManager 实例——默认情况下，只有“主”服务管理器，它使用 'services' 配置键或模块的 getServiceConfig() 方法返回的数组进行配置。
  • 插件管理器——这些扩展Zend\ServiceManager\PluginManager扩展Zend\ServiceManager\ServiceManager了一些专门的功能。这些分布在框架中的许多组件中，并提供以前已知的功能（在 ZF2 的早期版本中）作为插件加载器/代理。这些插件管理器是初始化视图助手、控制器插件和控制器本身的东西。
  • 其他“经理” ——诸如Zend\ModuleManager\ModuleManager和之类的东西Zend\Session\SessionManager。这些与 ServiceManager 无关，只是碰巧将“Manager”作为其名称的后缀。

我认为您可能会在尝试将定义分配给未考虑任何特定定义的术语（经理）时感到困惑。作为 的作者Zend\ModuleManager，我可以告诉你，我最初将组件开发为Zend\Module（我真的不喜欢 Manager 作为后缀）。这是在我们每周一次的 IRC 会议上决定的，它Zend\Module是模棱两可的，加上“经理”后缀会以某种方式解决这种模棱两可的问题。显然，我在这件事上的票数超过了我。我的观点是，Zend\ModuleManager根据任何定义，都没有发展到成为“经理”的任何规范。

服务

在 ZF2 中，关于Zend\ServiceManager，“服务”只是对象（技术上也可以是数组）。ServiceManager 组件可以被认为是您的应用程序可能需要的各种“服务”（对象）的简单键值注册表。这些“服务”通常是配置的邮件程序、记录器、数据库适配器、应用程序配置等。当然，ServiceManager不仅仅是一个简单的注册表，它的主要功能是将服务（及其依赖项）的实例化推迟到他们实际上是需要的；又名延迟加载）；我写了一篇博文，深入解释了 ServiceManager 的各种特性。

我不小心习惯了创建管理器并为 ServiceManager 提供工厂，以便您可以使用 $this->getServiceLocator()->get('managerName) 访问管理器

我认为在这种情况下，您可能会在这里将“经理”一词与“服务”混淆。使用 ServiceManager 注册的东西可以简单地称为“服务”。这可能会令人困惑，因为您确实可以将某种“管理器”注册为服务。例如，您可以有一个“会话”服务，它是Zend\Session\SessionManager. 进一步的混淆随之而来，因为术语“服务”通常指的是构成服务层一部分的类。

所以，不幸的是，是的，ZF2 中的术语可能有点模糊，但是一旦你理解了几个相对简单的核心概念，伟大的设计确实会带来一些惊人的灵活性，在我看来，这是其他大多数人无法比拟的现有的框架。

希望这可以帮助。

于 2012-09-05T02:50:55.900 回答