Design patterns 服务层=应用层=抓取控制器层

我认为服务/应用程序层与Larman描述的Grass Controller是一样的，它是GUI层之外的第一个委托给域层的对象，应该可以从不同的GUI中重用

服务（Evans）层与应用（Fowler）层相同，因为Fowler自己在关于“贫血域模型”的“bliki”中这样说：

引述： “应用层[服务层的名称]：定义 软件应该执行并指导表达域对象 解决问题。该层负责的任务是 对业务有意义或与客户互动所需 其他系统的应用层。该层保持薄。它 不包含业务规则或知识，但仅协调任务 在下一步中，代理将致力于域对象的协作 分层。它没有反映业务情况的状态， 但是，它可以有一个状态，该状态可以反映用户任务的进度 用户或程序。”

现在考虑上面的描述（也见fowler的PEAA书，关于从用例中识别服务层方法），也考虑Fowler在服务层描述中的图片，说明服务层是在这个URL的“用户界面”之后的第一层：

现在比较上面提到的服务/应用层描述 用Larman关于抓取控制器的一些话（在第三章） 他最畅销的OOAD书籍《应用UML和模式》的版本，age 302-306) : “…UI层之外接收和协调的第一个对象 （“控制”）系统操作 “…表示一个用例场景，其中系统事件 发生……” “…通常，控制器应将工作委托给其他对象 这需要完成；它协调或控制活动 本身做不了多少工作……”

我认为Larman的抓取控制器层与 Evans/Fowler的应用程序/服务层。其他人不同意吗？ 然后请解释这些概念之间的显著差异，以及控制器类而不是服务/应用程序类的一些示例

---

我的问题是因为有人说创建模型域对象是控制器的责任，而不是其他服务/应用层的责任。但是你能给我一个服务层类和控制器类之间的区别的例子吗

实际上，用户界面控制器和域控制器是最常用的模式

UI控制器以MVC模式协调对视图的访问

域控制器协调对域的访问，它被称为服务层（我更喜欢Fowler）或应用层（Evans）

两者都是间接层（Façade模式），用于在子系统/层之间解耦类。它带来了模块化和更好的可维护性（您可以将域交换为远程服务，或者将视图从HTML交换为Flex，只需更改间接层）

抓取控制器似乎是两者的混合体。我建议您仅将此术语用于分析，而不是用于实现

---

希望有帮助

这些课程是按惯例规定的吗？我有点喜欢在它们上面存储状态，我觉得更简单…@Wanderson Santos，imo，不应该将控制器作为UI和域分开。在MVC中，没有这样的东西。控制器协调（业务）服务（反过来处理/转换/处理（域）模型）和视图完成的逻辑。每个控制器（C）使用（业务）服务获取模型（M）并提供具有该模型（M）的视图（V）。M-V-C的分离允许您交换视图技术，而不是使用外观模式。当您注意到多个客户端（客户端是另一个服务或控制器-内部或客户端是外部系统）使用多个（组）服务时，应将外观模式用于服务。