Zend Framework 2中Service和Manager类之间的区别

Question

我对这个Manager和Service类名后缀感到有些困惑.

据我了解的不同,Managers负责处理(创建,检索,删除......)某些类型的实体.例如,ModuleManager负责加载和返回Modules.在这种情况下,你确实关心实际的实体,Module.

但是,Services是提供接口来执行cetain类型的流程逻辑的类.例如,a LogService将给定的日志消息发送到定义的日志编写器.你不关心它在哪里以及它做了什么,你只是想让管理员了解刚刚发生的事情.

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

我是否得到了真正的区别Services和Managers错误？甚至还有区别吗？是Managers没有可能从继承Services的概念？

Answer 1

我将尝试为您分解ZF2中的经理和服务.

经理

不幸的是,"经理"这个词在引用类时是非常含糊不清的,在ZF2中,与使用这个词的方式有点不一致.因此,对于ZF2中的"经理"来说,确实没有权威的定义.目前,ZF2中的"经理人"最好像这样分解:

• ServiceManager - 的一个实例Zend\ServiceManager\ServiceManager.可以有多个ServiceManager实例 - 默认情况下,只有"main"服务管理器,它配置了'services'配置键或Module的getServiceConfig()方法返回的数组.
• 插件管理器 - 这些扩展通过一些专用功能Zend\ServiceManager\PluginManager扩展Zend\ServiceManager\ServiceManager.它们遍布框架中的许多组件,并提供先前已知的(在早期版本的ZF2中)作为插件加载器/代理的功能.这些插件管理器是初始化诸如视图助手,控制器插件和控制器本身之类的东西.
• 其他'经理' - 喜欢Zend\ModuleManager\ModuleManager和Zend\Session\SessionManager.这些与ServiceManager无关,但恰好将'Manager'作为其名称的后缀.

我认为您可能会在尝试为术语(Manager)分配定义时考虑到任何特定定义.作为作者Zend\ModuleManager,我可以告诉你,我最初开发的组件是Zend\Module(我真的不喜欢Manager作为后缀).它在决定我们每周IRC会议之一即Zend\Module是含糊不清,与"经理"后面添加它会以某种方式解决歧义.显然我在这个问题上被投了票.我的观点是,Zend\ModuleManager根据任何定义,没有发展成任何"经理人"的规范.

服务

在ZF2中,关于Zend\ServiceManager"服务"只是对象(技术上也可以是数组).可以将ServiceManager组件视为应用程序可能需要的各种"服务"(对象)的简单键值注册表.这些"服务"通常是配置的邮件程序,记录器,数据库适配器,应用程序配置等.当然,ServiceManager 不仅仅是一个简单的注册表,它的主要功能是推迟服务(及其依赖项)的实例化,直到他们确实需要; 又懒加载); 我写了一篇博文,深入介绍了ServiceManager的各种功能.

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

我认为在这种情况下,您可能会将"经理"这个词与"服务"混为一谈.使用ServiceManager注册的内容可以简称为"服务".这可能令人困惑,因为您确实可以将某种"经理"注册为服务.例如,您可以拥有一个"会话"服务,该服务是一个实例Zend\Session\SessionManager.随之而来的是混乱,因为术语"服务"通常是指构成服务层一部分的类.

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

希望这可以帮助.