grails_Grails最佳做法

grails

我在IntelliGrape工作，该公司专门从事Groovy＆Grails开发。 本文是Grails项目遵循的最佳实践的基本列表，这些列表从邮件列表，Stack Overflow，博客， 播客以及IntelliGrape的内部讨论中收集。 它们分为控制器，服务，域，视图，标签库，测试和常规。

尽管许多建议通常适用，但此处的建议专门针对Grails 2.0。

控制者

1. 不允许控制器接任其他角色。 控制器的作用是接受传入的请求，检查权限等，向域或服务询问结果，以所需的格式（例如HTML，JSON或XML）将结果返回给请求者。 保持控制器尽可能薄。 不要在控制器内执行业务逻辑，查询或更新。
2. 如果控制器表示单个域类，请使用“ <DomainClass> Controller”的标准命名约定。
3. 避免代码重复-常见操作应作为闭包或方法提取。 有关更多信息，请参见此博客条目 。
4. 将复杂的数据绑定拆分为命令对象。 您可以使命令对象丰富（就像丰富的域类一样）。 在某些情况下，创建命令对象的层次结构也很有用。

服务

1. 服务是复杂业务逻辑或粗粒度代码的正确选择。 如果需要，可以轻松将服务API公开为RESTful / SOAP Web服务。
2. 默认情况下，服务是事务性的，但是如果服务的任何一种都不更新持久性存储，则可以使它们成为非事务性的。

观看次数

1. 保持视图尽可能简单-避免将业务或数据库逻辑放在这一层的诱惑。
2. 使用布局可确保在应用程序页面的全部或子集上具有一致的外观。
3. 保持您的观点干燥（“不要重复自己”）。 将重复的内容拆分为模板。
4. 将自定义TagLib用于常见的UI元素。

域

1. 支持将模型领域特定的逻辑放在自己的领域中。 适用于具有很少依赖性的单个域的所有内容都应归入其域类。 但是，仅将其限制于特定于该域的逻辑-处理一组域的更复杂的业务逻辑属于服务。
2. 要重用常见的部分查询或分解复杂的逻辑，请使用命名查询并将它们按需链接在一起，就像一个通常链接jQuery函数调用一样。
3. 不要在域文件夹中混用任何其他通用实用程序类或值对象，而可以将它们放在src / groovy中。 如果这些类需要支持验证，则可以使用@Validateable对其进行注释。
4. 使用明智的构造函数实例化域对象，避免出现任何不必要的状态并仅构造有效对象。

标签库

1. 保持单个标签灯亮。 标签可以调用其他标签，并且可以根据需要将标签分成可重用的子标签。
2. TagLib被认为是MVC体系结构中视图层的一部分，但是可以根据需要对域进行挖掘，以对数据进行组合或格式化以进行显示。 仍然遵循最小化（即不禁止）与域直接交互的方法。
3. 它应该包含比渲染更多的逻辑。 尽管可以进行一点渲染。
4. 使用多个自定义标记库可以更好地组织。

测试中

1. 偏爱单元测试而不是集成测试。 除了运行/调试更快之外，它们还可以更好地执行松耦合。 服务测试是一个例外，集成测试通常更有用。
2. 在单元测试中，使用save（validate：false）保存未完全加载的对象。

配置槽

1. 将所有特定于环境的设置放在Config.groovy中，例如serverURL，随环境而异的常量等。
2. 将个人设置（例如本地数据库用户名或密码等）保存在<Local> Config.groovy文件中，并将其添加到版本控制忽略列表中，以便每个团队成员可以根据其特定需要覆盖配置。
3. 有些争议，但我们建议设置grails.gorm.failOnError = true，以便在保存对象时域验证失败时引发异常。 鉴于此，您不再需要检查保存是否成功。
4. 默认情况下，在Grails 2.0中，“ grails.hibernate.cache.queries = true”会自动缓存查询，而无需添加cache：true。将其设置为false，仅在真正有助于性能的情况下才进行缓存。

其他一些技巧

1. 了解和遵守Grails约定，因为Grails受约定驱动。 使用这些约定将使您作为开发人员的生活更加轻松。
2. 要在不同的程序包中组织Grails工件，请不要执行com.businessname.appname.domain和com.businessname.appname.controller 。 否则，在FooController中，我们最终将导入Foo类。 由于Grails已经将这些工件保存在不同的文件夹中，因此无需进一步分离。 请参阅此博客 。
3. Fixtures插件可用于在开发过程中引导您的数据。
4. 将应用程序的可重用部分开发为Grails插件。 这些插件可以单独测试，使用它们可以从您的主应用程序中消除复杂性。 如果您认为其他人可以从中受益，请考虑将其发布在公共插件存储库中。
5. 更新支架模板以生成您的项目特定的视图和控制器。
6. 在静态脚手架不再满足您的要求之前，请优先使用动态脚手架而不是静态脚手架。 例如，如果仅需要修改“保存”操作，则可以覆盖该“保存”操作并在运行时动态生成脚手架代码。
7. 始终在DataSource.groovy中提供数据库重新连接属性是很好的。
8. 始终确保您包括一个外部化的配置文件（即使它是一个空文件），以便可以在生产中覆盖任何需要覆盖的配置，而无需生成新的war文件。
9. 如果您需要对正在使用的插件进行小的更改，例如，石英监视器插件的change list.gsp随应用程序主题一起使用，那么您可以覆盖这些文件，而不必为此插件进行内联通过遵循相同的目录结构或软件包。 之所以可行，是因为应用程序比使用的插件具有更高的优先级。
10. 可以将域的所有自定义验证器放在共享的验证器文件中，以支持其他域之间这些约束的重用。 请参阅此处的示例。
11. 要在您的应用程序中安装任何插件，最好在BuildConfig.groovy中声明它，而不是使用install-plugin命令。 阅读此主题以获取详细说明。

我错过了什么吗？ 您在项目或组织中遵循的与Grails开发相关的最佳实践是什么？ 请分享它们作为评论，以便我们进一步丰富文章。

翻译自: https://www.infoq.com/articles/grails-best-practices/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

grails