grails最佳实践

------以后根据这个改网站

我工作于IntelliGrape,一个专用Groovy&Grails开发项目的公司.本文列举了我们Grails项目遵循的几个基本的最佳实踐,它们通过邮件,StackOverflow,博客,podcasts,和公司内部的讨论收集.按照controller,service,domain,views,taglibs,测试和其它分类.

本文的建议主要针对Grails2.0.

Controller

1.不要让Controller扮演多个角色.控制器的角色仅仅是接收请求,检查权限等,复杂逻辑由domain或service处理,并根据期望的格式返回HTML,XML,JSON等.尽量保持控制器简单.不要在控制器中处理复杂业务逻辑,查询,更新等.

2.如果控制器只是关于某个domain类的逻辑,请使用标准的命名约定"<DomainClass>Controller".

3.避免代码重复-將重复编码封装成闭包.查看这里获取更多信息.

4.將复杂的数据绑定拆成commonobject.你也可以编写富commonobject.建立commonobject的继承结构有时会很有用.

Service

1.service是处理复杂业务逻辑的正确地方.如有需要,service可以很容易的暴露为RESTful/SOAP服务.

2.service默认开启事务,若无持久化操作,也可以设置成非事务的.

Views

1.尽量保持views简单--避免在模版中处理复杂业务逻辑

2.使用布局模版,子模版保证外观风格一致.

3.让模版遵循DRY原则.把重复的东西封装成模版.

4.使用自定义标签,封装通用的UI元素

Domain

1.处理domain自身业务逻辑的好地方.任何适用于单个domain,与外部依赖较少的逻辑都可放入.但是确保逻辑只针对domain本身--更复杂的需要多个domain协作的业务逻辑应方到service中.

2.重用业务逻辑或拆分复杂业务逻辑,使用命名查询并以链式组合,就像jQuery的函数链式调用一样.

3.不要在domain目录中混入普通的工具类或值对象,把它们放到src/groovy目录中.如果这些类需要支持数据验证,可以使用@Validateable注解.

4.为domain对象使用显示的构造函数,避免无效的状态而仅构造有效的对象.

Taglib标签库

1.确保每个标签轻量.标签可以调用其它标签,最好將标签拆成几个可重用的子标签.

2.标签库被认为是MVC结构中view的一部分,但也可以放入domain类中,根据需要收集或格式数据显示.但还是要遵循domain类最小依赖原则.

3.它应包含比渲染更多的逻辑;尽管少量的渲染是好的.

4.使用多个自定义标签更好的组织页面

测试

1.单元测试优于集成测试,运行和更快.一个例外是,测试service,集成测试的信息会更有用.

2.在单元测试中,使用save(validate:false)保存未完整加载的对象.

Config.groovy

1.所有的环境参数在Config.groovy指定,如serverURL,环境相关的常量,等等.

2.將个性化配置(如本地的数据库用户名,密码)放到单独的<Local>Config.groovy文件中,并加入版本管理工具忽略列表中,这样团队中的成员的个性设置不会相互影响.

3.可能有些争议,但我们还是建议设置grails.gorm.failOnError=true,这样当保存对象发生验证错误时,异常可以立即抛出.这样的话,你就不需要检查保存是否成功了.

4.在Grails2.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已经將这些工件放到指定的目录中,它们就不需要再被拆分.查看blog.

3.fixtures插件可以帮助你在开发环境中初始化数据.

4.將应用的可重用部分做成插件.这些插件可以单独的测试和随时从主项目中移除.如果你认为该插件对其它开发者有帮助,也可以发布到公共的插件仓库中.

5.修改脚手架模块生成工件,定制自己的页面和控制器生成策略.

6.宁可用动态scaffolding而不选静态scaffolding,直到行为不能再满足你的需要.例如,仅仅是"save"操作需要修改,你就仅需覆盖"save"操作,而其它操作代码还是可以在运行时动态生成.

7.最好在DataSource.groovy中提供re-connectionproperties配置.

8.确保总是包含外部配置文件(甚至是空文件),这样可以在生产环境中覆盖原有配置选项而不用重新打包.

9.如果需要对使用的插件做少量修改,如修改quartzmonitor的list.gsp文件,你可以不用直接修改插件里的文件,而是重新定义一个相同的目录和包来覆盖.它比插件的优先级高.

10.所有domain的自定义验证器可以放到单独的文件中,这样可以提高重用度,其它domain有需要也可使用.这里有个例子.

11.应用要安装插件,最好在BuildConfig.groovy中定义,而不是使用install-plugin命令.查看该贴获取详细信息.