服务层=应用层= GRASP控制器层 [英] Service layer = Application layer = GRASP Controller layer

问题描述

我认为服务/应用层与Larman所描述的GRASP控制器是一样的，它是超出GUI层的第一个对象，它被委托给域层，并且应该可以从不同的GUI重用。

服务（Evans）层与Application（Fowler）层是一样的，因为Fowler自己在他的bliki中说到了Anemic Domain Model： http://martinfowler.com/bliki/AnemicDomainModel.html

报价：
应用层[他的服务层名称]：定义
软件应该做的工作，并指示表达域对象
解决问题本层负责的任务是
对于业务有意义，或者是与其他系统的
应用层交互所必需的，这个层保持很薄，它不包含业务规则或知识，而只是协调任务
，并委派工作到下一个
层中的域对象的协作。它没有反映业务情况的状态，
，但它可以具有反映
用户或程序的任务的进展的状态。

现在考虑上面的描述（并且还参见福勒的PEAA书，关于从用例中标识服务层方法），并且还考虑Fowler的服务层描述中的图片，其示出了服务层是用户界面： http://martinfowler.com/eaaCatalog/serviceLayer.html p>

现在将上面提到的Service / Application层描述
与一些关于GRASP控制器的Larman的话进行比较（在他的畅销书的第3
版OOAD书Aplying UML and patterns，age
302-306）：
...第一个对象超出UI层，接收并协调
（控制）系统操作。 ..
...表示系统事件
发生的用例场景...
...通常，控制器应委托其他对象工作
需要做;它协调或控制活动。它
本身不做太多工作....

我认为Larman的GRASP控制器层与
相同Evans / Fowler的应用程序/ service layer。其他人不同意？
然后请解释这些概念之间的显着差异，以及Controller类而不是Service / Application类的一些示例。

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

解决方案

实际上，UI控制器和域控制器是最常用的模式。

UI控制器以MVC模式协调对View的访问。

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

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

GRASP控制器似乎是一个混合。我建议您仅将此术语用于分析，而不是实施。

希望它有帮助！

I think service/application layer is the same thing as Larman describes as GRASP Controller, being the first object beyond the GUI layer that delegates to the domain layer, and should be reusable from different GUI.

Service (Evans) layer is the same as Application (Fowler) layer because Fowler himself says so, in his "bliki" about the "Anemic Domain Model": http://martinfowler.com/bliki/AnemicDomainModel.html

Quote: "Application Layer [his name for Service Layer]: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program."

Now consider the above description (and also see fowler's PEAA book, regarding identifying service layer methods from the use cases) and also consider the picture in Fowler's description of Service layer that illustrates the Service Layer being the first layer after the "user interface" at this URL: http://martinfowler.com/eaaCatalog/serviceLayer.html

Now compare the above mentioned Service/Application layer description with some of Larman's words about the GRASP Controller (in the 3rd edition of his best-selling OOAD book "Aplying UML and patterns", age 302-306) : "...first object beyond the UI layer that receives and coordinates ("controls") a system operation..." "...represents a use case scenario within which the system event occurs..." "... Normally, a controller should delegate to other objects the work that needs to be done; it coordinates or controls the activity. It does not do much work itself...."

I think that Larman's GRASP Controller layer is the same as Evans/Fowler's Application/Service layer. Do other people disagree ? Then please explain the significant differences between these concepts, and some example of Controller class instead of Service/Application class.

My question is born because some say that the creation of model domain objects is the responsibility of the controller, instead of the other service / application layer. But could you give me an example of service layer class and the difference between controller class?

解决方案

Actually there's UI Controller and Domain Controller as most used patterns.

UI Controller coordinates access to View, in an MVC pattern.

Domain Controller coordinates access to Domain, and it's called Service Layer (Fowler, which I prefer) or Application Layer (Evans).

Both are indirection layers (Façade Pattern), used to decouple classes between subsystems/layers. It brings modularity and better maintainability (you can swap domain for remote services or swap view from HTML to Flex, and just change the indirection layer)

GRASP Controller appears to be an hybrid of both. I recommend you to use this term only for analysis, not for implementation.

Hope it helps!

这篇关于服务层=应用层= GRASP控制器层的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！