design-patterns - 服务层 = 应用层 = GRASP Controller 层

Question

关闭。这个问题不符合Stack Overflow guidelines .它目前不接受答案。












想改进这个问题？将问题更新为 on-topic对于堆栈溢出。

3年前关闭。




Improve this question




我认为服务/应用程序层与 Larman 描述为 GRASP Controller 的东西相同，它是 GUI 层之外的第一个对象，它委托(delegate)给领域层，并且应该可以从不同的 GUI 重用。

服务 (Evans) 层与应用程序 (Fowler) 层相同，因为 Fowler 本人在他关于“贫血域模型”的“bliki”中这么说:http://martinfowler.com/bliki/AnemicDomainModel.html

引用:
“应用层[他的名字为服务层]:定义工作
软件应该做并指导富有表现力的领域对象
解决问题。该层负责的任务是
对业务有意义或与客户互动所必需的
其他系统的应用层。该层保持薄。它确实
不包含业务规则或知识，仅协调任务
并将工作委托(delegate)给下一个领域对象的协作
下层。没有反射(reflect)事业状况的样子，
但它可以具有反射(reflect)任务进度的状态
用户或程序。”

现在考虑上述描述(另请参阅 fowler 的 PEAA 书，关于从用例中识别服务层方法)，并考虑 Fowler 对服务层的描述中的图片，该图片说明服务层是“用户界面”之后的第一层这个网址:http://martinfowler.com/eaaCatalog/serviceLayer.html

现在比较上面提到的Service/Application层描述
加上拉曼关于 GRASP Controller 的一些话(在第 3
他的畅销 OOAD 书籍“应用 UML 和模式”的版本，年龄
302-306) :
“...第一个超出 UI 层的对象，它接收和协调
(“控制”)系统操作……”
"...代表一个用例场景，其中系统事件
发生……”
“......通常， Controller 应该将工作委托(delegate)给其他对象
这需要做；它协调或控制事件。它
本身并没有做太多的工作......”

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

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

Answer 1

实际上有 UI Controller 和域 Controller 作为最常用的模式。

UI Controller 以 MVC 模式协调对 View 的访问。

域 Controller 协调对域的访问，它被称为服务层(Fowler，我更喜欢)或应用层(Evans)。

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

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

希望能帮助到你!