雖然網上大量有人在宣傳從Spring+Struts平台遷移到Grails平台的平緩事實上也是如此但資深的Spring+Struts平台開發人員遷移到Grails平台仍然需要有一些轉變其中大部分都是開發思想或者開發思路的轉變
第一 開發方式的轉變
Spring+Struts平台的開發是平緩的不管是CRUD還是復雜的業務Spring+Struts平台都要一視同仁一步步來對於CRUD它的簡單只是在業務層其他的數據層表現層Action頁面和它們之間的配置一個都不能少該做的都要做到而復雜的業務和簡單的CRUD的不同僅僅表現在業務層多做的事情也大部分在業務層
而Grails平台的開發則是曲線式的先快後緩對於CRUD式的業務在Grails平台只要一兩個動作就完成了全部的功能當然我們必須對頁面做一定的修改以達到客戶的要求當CRUD業務完成以後我們再在它們的基礎上添加復雜的業務
往往從Spring+Struts平台轉移過來的開發人員會喜歡契約式的開發而討厭Spring+Struts的配置式的開發對於Grails平台對CRUD開發的簡化反而比較忽視因為對於一個大型項目來說CRUD所占的比例不大而且很多開發人員也不認為Grails平台的腳手架產生的代碼對他們有多少幫助因為頁面需要定制
其實從我的經驗來說對於一個大型項目CRUD所占的比重大約為五分之一到四分之一的樣子而在小項目中CRUD所占的比重會更大一些因此雖然一個大項目開發完成以後我們不記得我們曾做過CRUD的開發但不可否認的是CRUD的開發在Spring+Struts平台的確占了我們一部分的開發時間Grails平台對這部分時間的節省對我們來說也是值得慶賀的
所以在Grails開發平台當然拿到一個模塊的時候我們第一步要做的不是按照業務的要求按部就班的進行開發而是首先要把其中的CRUD部分抽取出來交給Grails平台來幫我們實現然後我們在它的基礎上去做更為復雜的業務這就要求我們在設計SD文檔和demo的時候要盡量將業務中的CRUD抽取出來集中而不是分散這樣有利於Grails平台來幫我們實現CRUD的功能
第二
有關契約
契約式編程相比較於配置式編程
在效率上的確高了很多
但需要注意的是
我感覺
對於大型項目來說
在編碼的同時
維護一下controller
action
服務層和頁面的關系仍然是有很大的必要的
但這種維護是文檔式的維護
不會干擾到程序和測試服務器的運行
一旦有了這個文檔
在項目的維護過程中的作用是顯而易見的
當然了
這種維護要我們更為細心
不要出錯
因為如果在Spring+Struts平台
配置文件出錯的話
測試服務器運行時會出問題的
這也是Spring+Struts平台配置討厭的一個原因
一個人維護出錯
down過他的代碼的人的測試服務器都跑不起來
但文檔維護顯然沒有這樣的糾錯機制
它的正確性需要的是維護人員的細心
就我的經驗而言
使用契約的地方越多
就越需要文檔
維護文檔雖然會降低你的開發速度
但在項目的維護過程中
對你的維護效率的提高又是不言而喻的
特別是開發人員和維護人員不是同一個人的時候
第三
有關頁面開發
傳統的Spring+Struts平台的開發
我們直接把demo的頁面拿來
轉化成jsp文件
再在相應的位置填充所需要的變量
然後跟後台交互
而Grails平台的開發
我們是先開發CRUD業務
即由平台幫我們生成gsp文件
然後再根據demo的頁面要求
修改它的Layout和填充必要的樣式
然後
再由CRUD業務的頁面鋪展開來
繼續完成其他的較為復雜的業務
復雜業務的gsp文件可以由demo的頁面直接轉化過來
From:http://tw.wingwit.com/Article/program/Java/ky/201311/27979.html
