Grails设计最佳实践

Grails被设计为基于交互式敏捷的快速开发框架，该框架提倡使用约定而非配置。 本文介绍了Grails的用法和最佳实践。

域驱动设计

• 始终使用域驱动的设计 ：首先创建基本的域模型类，然后使用脚手架将其联机。 这将帮助您保持动力并更好地了解自己的领域。
• 使用测试驱动方法：域模型测试用例提供了一种很好的方法来测试验证。
• 验证：使用验证器使您的域对象井井有条。 自定义验证器并不难实现，因此如果情况需要，不要害怕自己动手。 最好将验证逻辑封装在您的域类中，而不是使用狡猾的控制器黑客

遵循Grails公约

• 遵循Grails约定 ：Grails是约定驱动的开发，需要按照约定进行遵循，这意味着View应该只是视图。 控制器应该只是控制器。
• 事务性服务 ：保持事务性服务
• 功能逻辑：功能 逻辑将作为服务和模型对象的一部分实现。 这意味着将请求传递给Controller，然后Controller将依次调用服务。

依赖注入

Grail基于对约定的依赖注入，因此我们需要关注文件夹约定以将组件放置在适当的grails-app / folder和适当的命名约定上

• 位置约定 ：服务进入服务文件夹。 控制器进入控制器的文件夹。
• 命名约定 ：如果您具有Xxx模型对象，并且需要一个控制器和服务，则您的控制器和服务应命名为XxxController和XxxService。 圣杯将自动基于电线命名约定

演示/查看

• 使用分页 ：对大型数据集进行分页可提供更好的用户体验，并改善整体演示性能。
• 使用自定义标签 ：为您的UI开发可重用的自定义标签。 它将提高整体开发效率并增强维护。
• 更智能地使用布局 。 处理布局中的基本Flash消息显示，而不是对每个视图重复显示。
• 选择一个合适JavaScript库 。 选择一个对您的其余应用程序有意义的Ajax库。 下载库需要时间，因此请尽量减少正在使用的库的数量。
• 使用基于约定的布局 ：优于显式Meta标记的基于约定的布局。 通常，与执行超魔术分支相比，针对某个特定动作的特定布局可以使事情更具可维护性。 需要为控制器设置页面的子集样式时，请利用Meta标记样式，而其余部分则使用约定布局。
• 外部化配置文件：始终包括一个外部化的配置文件，这样就可以完成需要在生产中覆盖的任何配置，而无需生成新的war文件
• 首选动态脚手架 ：始终比静态脚手架更喜欢动态脚手架。
• 使用Datasorce配置：使用 DataSource.groovy属性文件配置datasorce
• 重复使用自定义验证器：所有自定义验证器都放置在共享验证器的文件中，以支持这些约束在其他域之间的可重用性。
• 在Web层中避免逻辑：我们应该避免在Web层中放置大量逻辑，以使表示层和业务层之间清晰分开。
• 使用BuildConfig.groovy：要在应用程序中安装任何插件，请在BuildConfig.groovy中声明它，而不要使用install-plugin命令。
• 保持简单的视图 ：使视图尽可能简单，并将服务层用于业务逻辑
• 重新使用模板和自定义标签库：将共享内容拆分为模板和g：render并为常见的UI元素构建自定义标签库
• 使用布局 ：使用布局可在整个UI中保持一致的外观。
• 干燥：保持您的意见干燥（“不要重复自己”）。 将重复的内容拆分为模板。

控制者

• 保持控制器精简：不要在控制器内执行业务逻辑，Web服务，数据库操作或事务。 保持控制器尽可能薄。 控制器的目的是接受传入的请求，为结果调用域或服务，然后将结果返回给请求者。
• 使用命令对象 ：利用命令对象进行表单提交。 不仅将它们用于验证-它们还可以方便地封装棘手的业务逻辑。 了解数据绑定。 Grails中的数据绑定选项非常丰富且微妙。
• 使用正确的命名约定 ：使用“ <DomainClass> Controller”的标准命名约定。
• 使用Flash范围。 Flash范围非常适合将消息传递给用户（涉及重定向）。
• 使用错误对象 ：利用您的域类上的错误对象来显示验证消息。 利用资源包使错误消息与您的应用程序使用案例相关。
• 应用过滤器 。 当您需要根据URL或控制器操作组合有选择地触发后端逻辑时，请应用过滤器

服务

服务是复杂业务逻辑或粗粒度代码的正确选择。 如果需要，可以轻松将服务API公开为RESTful / SOAP Web服务。

• 用于事务性：默认情况下，服务是事务性的，但是如果服务的任何方法都不更新持久性存储，则可以使它们成为非事务性的。
• 避免代码重复 –应提取通用操作并在整个应用程序中重复使用
• 无状态性 ：服务应无状态。 使用域对象进行状态完全操作。

域

• 覆盖setter和getter ：充分利用覆盖setter和getter的功能，使属性更易于使用。
• 取消合并复杂查询 ：通过链接组合命名查询以准备复杂查询。
• 将特定逻辑限制到域： 保持特定于该对象的逻辑。 处理对象组的更复杂的业务逻辑属于服务
• 使用域对象为域逻辑建模 ：将域逻辑移至服务是不便的持久层的困扰
• 不要与域文件夹混合：不要与域文件夹中的任何其他常见实用程序类或值对象混合； 而是可以使用src / groovy。
• 使用明智的构造函数：使用明智的构造函数实例化域对象，以避免出现任何不必要的状态并仅构造有效的对象。

标签库

• Simple taglib：使标签保持简单，并根据需要将标签分成可重用的子标签。
• 应该包含逻辑： Taglib应该包含比渲染更多的逻辑
• 使用多个自定义标签库 ：使用多个自定义标签库可以更好地进行组织。

插入

• 可重复使用的插件：将应用程序的可重复使用功能和逻辑部分构建为独立的可重复使用的Grails插件，可以对其进行单独测试，从而从您的主应用程序中消除复杂性。
• 公共插件存储库：可以在公共插件存储库中发布跨多个应用程序的可重用插件。
• 使用fixture插件 ：在开发过程中引导您的数据
• 覆盖插件以进行小的更改 ：如果您需要对正在使用的插件进行较小的更改，则可以使插件遵循相同的目录结构或程序包，而无需为此插件内联，而可以使这些文件内嵌。
• 使用onChange ：如果插件添加了动态方法或属性，以便在重新加载后保留这些方法和属性，请使用onChange。
• 使用本地插件存储库 ：本地插件存储库有多种用途，例如在应用程序之间共享插件
• 模块化大型或复杂的应用程序 。 使用插件将大型或复杂的应用程序模块化，以带来“关注分离”模式。
• 为您的插件编写功能测试 。 为了使插件可靠，您应该编写功能测试。

测试中

• 测试驱动的开发方法： Grails提倡TDD方法意味着首先进行测试，以确保涵盖您的功能。
• 经常测试：经常测试，以便在出现故障时获得更快的反馈，从而更易于修复。 这有助于加快开发周期。
• 使用测试覆盖率 ：保持测试覆盖率，并尽可能避免测试覆盖率出现差距
• 支持单元测试而不是集成测试：运行/调试速度更快，它们可以更好地执行松耦合。 服务测试是一个例外，集成测试通常更有用。
• 使用持续集成（CI） 。 使用持续集成（CI）在各种环境中自动化构建和部署。
• 使用grails控制台进行测试 ：使用grails控制台进行测试，将Groovy控制台嵌入到您的Web UI中-这是检查正在运行的应用程序内部的宝贵工具。

部署方式

• 使用发布插件 ：使用发布插件将内部插件部署到您的Maven存储库。
• 使用持续集成（CI） 。 对于任何一支以上的团队来说，要捕获来自不同人员的变更合并在一起时出现的那些错误，这几乎是强制性的。
• 自动化过程：编写脚本以自动化任何重复性任务，从而减少错误并提高整体生产率。
• 熟悉资源插件 ：使您熟悉用于处理静态资源的资源插件

摘要

Grails的主要目标是以敏捷方式快速开发Web应用程序。 Grails基于约定优于配置和DRY（不要重复自己），并且不仅可以重用Grails中的现有Java代码，而且还可以通过它们快速，快速地构建健壮而稳定的Web应用程序。

参考： Tech My Talk博客中来自JCG合作伙伴 Nitin Kumar的Grails设计最佳实践 。

翻译自: https://www.javacodegeeks.com/2013/04/grails-design-best-practices.html