grails最佳实践

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

我工作于IntelliGrape, 一个专用Groovy&Grails开发项目的公司. 本文列举了我们Grails项目遵循的几个基本的最佳实踐, 它们通过邮件, Stack Overflow, 博客, podcasts, 和公司内部的讨论收集. 按照controller, service, domain, views, taglibs, 测试和其它分类.
本文的建议主要针对Grails 2.0.
Controller
    1. 不要让Controller扮演多个角色. 控制器的角色仅仅是接收请求, 检查权限等, 复杂逻辑由domain或service处理, 并根据期望的格式返回HTML,XML,JSON等. 尽量保持控制器简单. 不要在控制器中处理复杂业务逻辑, 查询, 更新等.
    2. 如果控制器只是关于某个domain类的逻辑, 请使用标准的命名约定 "<DomainClass>Controller".
    3. 避免代码重复 - 將重复编码封装成闭包. 查看这里获取更多信息.
    4. 將复杂的数据绑定拆成 common object. 你也可以编写富 common object. 建立 common object 的继承结构有时会很有用.
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. 在 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已经將这些工件放到指定的目录中, 它们就不需要再被拆分. 查看blog.
    3. fixtures 插件可以帮助你在开发环境中初始化数据.
    4. 將应用的可重用部分做成插件. 这些插件可以单独的测试和随时从主项目中移除. 如果你认为该插件对其它开发者有帮助, 也可以发布到公共的插件仓库中.
    5. 修改脚手架模块生成工件, 定制自己的页面和控制器生成策略.
    6. 宁可用动态 scaffolding 而不选静态scaffolding, 直到行为不能再满足你的需要. 例如, 仅仅是 "save" 操作需要修改, 你就仅需覆盖 "save" 操作, 而其它操作代码还是可以在运行时动态生成.
    7. 最好在DataSource.groovy中提供 re-connection properties 配置.
    8. 确保总是包含外部配置文件(甚至是空文件), 这样可以在生产环境中覆盖原有配置选项而不用重新打包.
    9. 如果需要对使用的插件做少量修改, 如修改quartz monitor的list.gsp文件, 你可以不用直接修改插件里的文件, 而是重新定义一个相同的目录和包来覆盖. 它比插件的优先级高.
    10. 所有domain的自定义验证器可以放到单独的文件中, 这样可以提高重用度, 其它domain有需要也可使用. 这里有个例子.
    11. 应用要安装插件, 最好在BuildConfig.groovy中定义, 而不是使用install-plugin命令. 查看该贴获取详细信息.