我认为服务/应用程序层与 Larman 描述的 GRASP 控制器相同，是 GUI 层之外委托给域层的第一个对象，并且应该可以从不同的 GUI 重用。
服务（Evans）层与应用程序（Fowler）层相同，因为 Fowler 本人在他关于“贫血领域模型”的“bliki”中是这么说的：http://martinfowler.com/bliki/AnemicDomainModel.html http://martinfowler.com/bliki/AnemicDomainModel.html
引用：
“应用程序层 [服务层的名称]：定义了
软件应该做并指导表达领域对象
解决问题。该层负责的任务是
对业务有意义或与业务互动所必需的
其他系统的应用层。该层保持较薄。确实如此
不包含业务规则或知识，仅协调任务
并将工作委托给下一个领域对象的协作
一层下来。它没有反映业务情况的状态，
但它可以有反映任务进度的状态
用户或程序。”
现在考虑上面的描述（另请参阅福勒的 PEAA 书，关于从用例中识别服务层方法），并考虑福勒的服务层描述中的图片，该图片说明了服务层是“用户界面”之后的第一层，位于这个网址：http://martinfowler.com/eaaCatalog/serviceLayer.html http://martinfowler.com/eaaCatalog/serviceLayer.html
现在对比一下上面提到的Service/Application层描述
Larman 关于 GRASP 控制器的一些话（在第 3 章中）
他的畅销 OOAD 书“应用 UML 和模式”的版本，年龄
302-306）：
“...UI 层之外的第一个接收和协调的对象
（“控制”）系统操作……”
“...代表一个用例场景，其中系统事件
发生……”
“......通常情况下，控制器应该将工作委托给其他对象
这需要完成；它协调或控制活动。它
本身并没有做太多工作......”
我认为 Larman 的 GRASP Controller 层与
Evans/Fowler 的应用程序/服务层。其他人不同意吗？
然后请解释这些概念之间的显着差异，以及控制器类而不是服务/应用程序类的一些示例。
我的问题之所以产生，是因为有人说模型域对象的创建是控制器的责任，而不是其他服务/应用程序层的责任。但是你能给我一个服务层类和控制器类之间的区别的例子吗？
实际上，UI 控制器和域控制器是最常用的模式。
UI 控制器以 MVC 模式协调对视图的访问。
域控制器协调对域的访问，它被称为服务层（Fowler，我更喜欢）或应用程序层（Evans）。
两者都是间接层（Façade Pattern），用于解耦子系统/层之间的类。它带来了模块化和更好的可维护性（您可以将域交换为远程服务或将视图从 HTML 交换为 Flex，只需更改间接层）
GRASP 控制器似乎是两者的混合体。我建议您仅使用该术语进行分析，而不是用于实施。
希望能帮助到你！
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
