歡迎您光臨本站 註冊首頁

grails最佳實踐

←手機掃碼閱讀     火星人 @ 2014-03-12 , reply:0
  

 我工作於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命令. 查看該貼獲取詳細信息.

    

 英文原文  OSCHINA原創翻譯



[火星人 ] grails最佳實踐已經有423次圍觀

http://coctec.com/docs/program/show-post-71364.html