文章: Grails最佳实践

标签: 文章 grails 最佳实践 | 发表时间:2012-05-11 13:00 | 作者:
出处:http://pipes.yahoo.com/pipes/pipe.info?_id=10560380f804c7341f042a2b8a03e117

我在IntelliGrape工作,这是一家专门使用Groovy & Grails进行开发的公司。本文是我们Grails项目遵循的最佳实践的基本清单,收集自邮件列表、Stack Overflow、博文, 播客IntelliGrape的内部讨论。它们分为控制器、服务、Domain、视图、TagLib、测试和其他。

这里的建议是专门针对Grails 2.0的,尽管其中的大多数是多个版本都适用的。

控制器

  1. 不允许控制器充当其他角色。控制器的角色就是接受传入的请求、检查权限等、问Domain或Service要结果、将结果用所需的格式(如 HTML、JSON或XML)返回给请求者。要让控制器保持苗条。别让它执行业务逻辑、查询或更新。
  2. 如果一个控制器代表了一个单一的Domain Class,使用标准的命名公式“<DomainClass>Controller”为控制器命名。
  3. 避免代码重复 - 通用的操作应该提取成闭包或者方法。更多信息参见 这篇博文
  4. 将复杂的数据绑定划分为一个Command对象。可以让Command对象丰富些(就像富Domain Class)。创建一个有层次的Comand对象在某些情况下也是有用的。

服务

  1. 服务是复杂业务逻辑或粗粒度代码的最佳候选。如果有必要,服务API可以很容易的暴露成一个RESTful/SOAP Web服务。
  2. 服务缺省为事务性的,但是如果服务的方法没有更新持久化存储,可以设置为非事务性的。

视图

  1. 尽量保持视图的简单 - 在这一层,抵制放置业务或数据库逻辑的诱惑。
  2. 使用布局(Layout)保证应用的所有页面或者页面子集有一个统一的外观。
  3. 让你的视图保持DRY(别重复你自己)。将重复内容放在模板中。
  4. 对通用的UI元素,使用自定义的TagLib。

Domain

  1. 最好将模型Domain特定的逻辑放在自己的Domain中。符合“单个Domain加少数依赖”的任何代码都应该被放到自己的Domain Class里。但仅限于那个Domain相关的逻辑,处理多个Domain的更复杂业务逻辑属于服务。
  2. 为了重用公共局部查询或者分解复杂逻辑,使用命名查询,并根据需要把它们组合起来,就像常见的jQuery函数链式调用一般。
  3. 别在Domain文件夹下混入其他的通用工具类或数值对象,它们应该呆在src/groovy目录下。如果这些类需要支持验证,可以用@Validateable对其进行注解。
  4. 使用有意义的构造函数实例化Domain对象,避免任何不必要的状态并只构造有效的对象。

TagLib

  1. 保持各标签的精简。一个标签可以调用其他标签,如果需要,一个标签可以分解成可重用的子标签。
  2. TagLib可以被认为是MVC架构中视图层的一部分,但深入Domain内部组装或者格式化数据显示也是可以接受的。依旧遵循(即不是完全禁止)最小化与Domain直接交互的原则。
  3. 它应该包含更多的逻辑,而非渲染;虽然有少许渲染还是不错滴。
  4. 为了更好的组织结构,可以使用多个自定义的TagLib。

测试

  1. 较之集成测试,更偏爱单元测试。不仅因为它们运行/调试更快,而且能更好地强制松耦合。服务的测试比较特殊,使用集成测试会更好些。
  2. 在单元测试中,使用save(validate:false)保存没有完全装入的对象。

Config.groovy

  1. 将所有环境特定的配置放在Config.groovy,如serverURL、每个环境下各异的常量等等。
  2. 将个人配置内容(比如本地数据库用户名或密码等等)放在 <Local>Config.groovy文件中,并加入到版本控制系统的忽略列表中,以便每个团队成员能够根据自己的特定需求覆盖配置。
  3. 虽有些争议,但我们建议设置grails.gorm.failOnError = true,这样只要保存对象时Domain校验失败就会抛出一个异常。由此,你就不再需要检查是否保存成功。
  4. 在Grails 2.0中,缺省“grails.hibernate.cache.queries = true”,毋须添加cache:true就会自动缓存查询。把它设为false,只在真正有助于提高性能时才缓存。

杂项

  1. 理解并坚持Grails的惯例,因为Grails就是惯例驱动的。使用这些惯例会让你的开发者生活更轻松。
  2. 在不同的包中组织Grails的制品,别用 com.businessname.appname.domaincom.businessname.appname.controller。否则在FooController中,我们将最终需要导入Foo类。 既然Grails已经将这些制品放在了不同目录下,它们就不需要再被分离了。可以参考这篇 博文
  3. fixtures插件可以在开发时用来初始化数据。
  4. 将你应用的可重用部分开发成Grails插件。这些插件可以独立测试,还可以消除你的应用的复杂性。如果你认为其他人会需要这些插件,你还可以把插件发布到公共的插件库中。
  5. 更新脚手架模板以生成你的项目特定的视图和控制器。
  6. 青睐动态脚手架,而不使用静态脚手架,除非前者不满足你的需求。例如,如果仅需要修改“save” action,你可以仅重载“save” action,在运行时动态生成其他脚手架代码。
  7. 总在DataSource.groovy中设置数据库的 重连属性是很好的习惯。
  8. 总保证自己应用中含有一个外部的配置文件(那怕是一个空文件),这样,在产品环境中需要覆盖任何配置时都无需重新生成一个新的WAR文件。
  9. 如果你想对你所使用的插件进行小的改动,例如改变quartz监控插件的list.gsp以符合应用主题,那么不要因为这点小改动而把插件源代码包含到项目里,你可以遵循相同的目录结构或包重载这些文件。原因是应用的优先级比插件高。
  10. Domain中所有自定义的校验可以放在一个共享的校验文件中,以便其他Domain重用这些约束。参见这里的 示例
  11. 在应用中安装任何的插件,最好在BuildConfig.groovy文件中声明,而不是使用install-plugin命令。请看 这个线索了解详情。

我还漏了什么吗?你们的项目或组织中遵循哪些Grails开发的最佳实践?可以通过评论分享出来,以便将来丰富本文的内容。

关于作者

Amit Jain是一位软件工程师,具有4年多的Java和Grails开发经验。他是一位敏捷的爱好者和认证的Scrum Master。在最近3年中,他就职于IntelliGrape,这是一家专门使用Groovy & Grails进行开发、 敏捷外包及项目的公司。参见 IntelliGrape网站

 

 

查看英文原文: Grails Best Practices 


感谢 胡键对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com。也欢迎大家通过新浪微博( @InfoQ)或者腾讯微博( @InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

相关 [文章 grails 最佳实践] 推荐:

文章: Grails最佳实践

- - InfoQ cn
我在IntelliGrape工作,这是一家专门使用Groovy & Grails进行开发的公司. 本文是我们Grails项目遵循的最佳实践的基本清单,收集自邮件列表、Stack Overflow、博文, 播客和 IntelliGrape的内部讨论. 它们分为控制器、服务、Domain、视图、TagLib、测试和其他.

文章: Hadoop MapReduce开发最佳实践(上篇)

- - InfoQ cn
本文是Hadoop最佳实践系列第二篇,上一篇为《 Hadoop管理员的十个最佳实践》. 百度技术沙龙第三十四期:机器学习之多媒体方向的思考(2013年1月12日 周六). 百度技术沙龙特约观察员火热招募中,2013,因为有你更精彩. GitHub运维专家Jesse Newland QCon分享Github ChatOps机器人与GitHub架构演进.

文章: Hadoop管理员的十个最佳实践

- - InfoQ cn
接触Hadoop有两年的时间了,期间遇到很多的问题,既有经典的NameNode和JobTracker内存溢出故障,也有HDFS存储小文件问题,既有任务调度问题,也有MapReduce性能问题.遇到的这些问题有些是Hadoop自身的缺陷(短板),有些则是使用的不当. 白皮书下载:利用您的私有或混合云加速业务成果.

jQuery最佳实践

- andi - 阮一峰的网络日志
上周,我整理了《jQuery设计思想》. 那篇文章是一篇入门教程,从设计思想的角度,讲解"怎么使用jQuery". 今天的文章则是更进一步,讲解"如何用好jQuery". 我主要参考了Addy Osmani的PPT《提高jQuery性能的诀窍》(jQuery Proven Performance Tips And Tricks).

PHP最佳实践

- xiangqian - 阮一峰的网络日志
虽然名字叫《PHP最佳实践》,但是它主要谈的不是编程规则,而是PHP应用程序的合理架构. 它提供了一种逻辑和数据分离的架构模式,属于MVC模式的一种实践. 我觉得,这是很有参考价值的学习资料,类似的文章网上并不多,所以一边学习,一边就把它翻译了出来. 根据自己的理解,我总结了它的MVC模式的实现方式(详细解释见译文):.

MongoDB最佳实践

- - NoSQLFan
将 MongoDB加入到我们的服务支持列表中,是整个团队年初工作计划中的首要任务. 但我们感觉如果先添加一项对NoSQL存储的支持,而不是先升级已支持的关系型数据库,可能对用户不太好,毕竟目前的用户都使用关系型数据库. 所以我们决定将引入MongoDB这项工作放到升级MySQL和PostgreSQL之后来做.

Play和Grails框架的优缺点

- - Java译站
框架为程序员提供了一些有用的特性从而简化了应用开发的过程. Java开发人员经常使用框架,由于框架非常流行,因此市场上你会发现各种各样的Java框架. 新手经常在论坛里面提问,“哪个Java框架最好. 首先,没有一个框架是最好的,因为他们都有自己的优点和缺点. 因此,你必须结合项目的需求来进行考虑.

PHP最佳实践(译)

- - CSDN博客Web前端推荐文章
原文:  PHP Best Practices-A short, practical guide for common and confusing PHP tasks. 译者: youngsterxyf. 本文档最后审阅于2013年3月8日. 由我, Alex Cabal,维护该文档. 我编写PHP程序已有很长一段时间了,当前我 经营着 Scribophile,由认真作家组成的一个在线写作团体,  Writerfolio,为自由职业者提供的一个易用写作工具集,以及  Standard Ebooks,一个图文并茂、无数字版权管理的公共领域电子书出版商.

Log4j最佳实践(原) - Mainz

- - 博客园_Mainz's Blog
本文是结合项目中使用 Log4j总结的最佳实践,非转载. 网上可以找到的是这一篇《 Log4j最佳实践》. 本来 Log4j使用是非常简单的,无需多介绍其用法,这只是在小型项目中;但在 大型的项目中使用 log4j不太一样. 大型项目非常依赖日志,因为解决线上问题必须依靠log,依靠大量的日志.

再谈RestAPI最佳实践

- - 企业架构 - ITeye博客
http://www.javacodegeeks.com/2014/05/rest-api-best-practices-reloaded.html ,仅供学习和参考,转载请注明出处. 近一年半,我参与了2到3个项目的工作,这些项目涉及到大量供“外部”使用的Rest API,稍后我们再来解释为什么要将“外部”这个词放在引号之中.