grails 教程_Grails初学者教程– Grails服务层

grails 教程

本教程将讨论Grails中服务层的重要性以及如何使用它。 它还说明了事务管理以及如何使用它。

介绍

关注点分离

考虑一下这样的类比：想象一家公司，其中为员工分配了不同工作性质的任务。 例如，假设有一个名为John Doe的雇员，其职责如下：

• 处理会计和支票付款的发放
• 接听客户电话以寻求产品支持
• 处理行政任务，例如预订航班以及高管人员的住宿
• 管理首席执行官的日程安排

如您所见，John的工作太复杂了，因为他需要在非常不同类型的任务上执行多任务。 从一项任务切换到另一项任务时，他需要改变心态。 他更有可能被压力释放并犯下许多错误。 从长远来看，他的失误可能会花费很多钱。 另一个问题是，稍后替换John并不容易，因为他过于复杂。

同样，在软件工程中，编写具有不同职责性质的类也不是一个好主意。 专家们的普遍共识是，单个类或源文件仅应涉及一种任务。 这称为“ 关注分离 ”。 如果发生了很多事情，这只会在以后引入错误和问题，因为应用程序的维护非常复杂。 尽管这个概念很容易陈述，但是对项目的影响却是巨大的！

考虑在Grails中使用控制器。 在控制器内部，我们可以执行以下操作：

• 处理路由逻辑
• 调用GORM操作以操纵数据库中的数据
• 渲染文本并将其显示给用户。

但是，建议不要在控制器内做所有这些事情。 Grails允许开发人员一起做所有这些事情以提高灵活性，但是应该避免这样做。 控制器的真正目的是处理路由逻辑，这意味着：

1. 接收用户的请求
2. 调用最合适的业务逻辑
3. 调用视图以显示结果

视图逻辑应注意Groovy服务器页面（GSP）文件的内部。 如果您不熟悉GSP ，请阅读此以前的教程 。

对于业务逻辑，应在服务层内部实现它们。 Grails对服务层具有默认支持和处理。

不要自我反抗（DRY）原则

使用服务层的另一个好处是，您可以在多个地方重用业务逻辑，而无需代码重复。 具有特定业务逻辑的单个副本将使项目更短（就代码行而言）且易于维护。 更改业务逻辑仅需要在一个特定位置进行更改。

不必重复代码是另一种称为“ 请勿自行拒绝（DRY）原则”的最佳做法的一部分

创建服务