以簡求快 Java快速開發架構LML簡介

         直入正題，閑話少敘。

         公司的形態，團隊的狀態，直接影響著我們對開發架構的選擇。正如上一篇以簡求快的博文所說，我們這樣的小成本Team Dev，更主要的是追求快而省。架構要開源，不必付出額外的成本；開發要快速，能夠更迅速的跟進客戶需求；代碼要簡單，任何經過簡單培訓的程式員都幾乎能夠勝任。

         領導一直再給我們灌輸快速開發的概念，在此處我予以沿用，不知道有沒有區別于敏捷開發的概念。對於概念，我是一竅不通，希望能有牛人解答我心中的疑惑，在此不勝感激。快，對我們這樣的輕型團隊很重要，幾乎也是最重要的一個因素。我們是不可能照著三年兩年去做一個項目，這樣我們的成本投入太多，反而有沒有把握收回。另外，代碼簡單也是重要的一個因素，因為我們團隊是快速的組合，可能頻繁的調動人員，離職的也不在少數，代碼簡單交接工作就更容易了。

         L ML在這種情況下的夾縫中誕生。我並非高手，所以LML也不算完善。

         首先：LML基於SSH。一直以來都被公司使用的Castle架構的快速簡潔而折服，在不追求運行效率的情況下，它堪稱完美，這當然還要感謝帶它來公司的某經理。但是，別人的終究是別人的，打心裡覺得自己的才是最好的。我水平有限，我沒有能力能夠在java平台上從頭開始造一款媲美Castle的架構。站在巨人的肩膀上，很多東西就不是很複雜了。SSH是為人熟知的開源Java Web架構，成熟而又穩定，使用率也比較靠譜，於是萌發了在SSH的基礎上在此封裝改造，形成一套架構的想法。

         其次：LML的模板引擎使用velocity，文法簡單，也可以很容易的借用codesmith等代碼產生工具產生模板。這實在是符合代碼簡單的原則！使用velocity的另外一個原因是我們在。Net中一直使用Nvelocity，他們二者文法非常類似，大部分代碼幾乎可以做到無修改移植。這一點以後會有案例的。

         第三：LML支援layout。無論是使用frame還是採用各種嵌入頁面的方式，都是為了避免重複的書寫公用的頁面，就像我們在某處聲明了一個公用的變數，那麼就不必要到處書寫公用變數所代表的值，另外也給修改帶來了方便。它其實相當於我們在asp.Net使用的母片。

         第四：html頁面（View）直接支援調用在後台提供的靜態或者非靜態方法。我覺得這樣也許被某些人深惡痛絕，我就曾經被一個不知其名的小同學罵過，但是這必然是很有用的。在原始的aps.net中，我們不分什麼前後台，之後出現了MVC，某些人（大部分是剛入門的吧？）一直在叫嚷視圖和邏輯分離。分離難道是絕對的嗎？個人認為，視圖確實應該和商務邏輯分離，而絕對不能和功能邏輯分離。商務邏輯此處是指為了實現一定的業務而做出的各種複雜的資料處理，功能邏輯此處是指為了展現資料而做的邏輯處理。我們查資料，那絕對不是目的，真正的目的是展現資料。就像某人懷才不遇，肚子裡有千萬資料，而不能展現，那還有什麼用呢。我希望能夠使用更簡便的方式來展現資料，比方更簡單的迴圈，比方這裡的我們可以直接調用後台方法進行簡單的資料處理，已達到更完美的資料展現。

         第五：拒絕大量的設定檔。有一種思想叫做，約定優於配置。我一直覺得SSH中需要我們配置的太多，就算一些微不足道理所當然的也要配，簡直不勝其煩。所以我大膽的做出決定如非必要，我將盡量的避免設定檔，比方我不再將Action託管給Spring。與其讓Spring採用request範圍來管理Action，還不如讓Action自生自滅的好，反正就算是託管給Spring，我也沒有見到效率更快。最新的SSH支援使用註解的方式來管理配置，但是我仍覺得這沒有那麼必要。所以對於一般情況，Struts的Action我使用通用配置，約定一下，什麼都變得輕鬆了。這一切都是對我們來說，不知道各位的情況是怎麼樣子的？當然還有一些其他的例如log4j等的配置，我也是能簡就簡。

         第六：局限的使用Model。自從物件導向大行其道，漸漸深入人心，好歸好，不好的一面也影響了我們的判斷。思維固式導致我們要求我們只根據使用者的ID查出姓名和年齡兩列是，我們也必須要查出一個具有四十個屬性的Model列表。這，好還是不好？我們更提倡使用原生的sql去查詢，快速而有效。當然，在編輯和儲存的時候，結合struts2的自動綁定功能，使用Model更能提高編碼效率。在使用效率一詞時，我是很謹慎的。這裡僅僅只是編碼效率或者開發效率，至於運行效率，一系列的綁定翻譯操作，最後再執行sql，總沒有直接執行sql更快吧？

         第七：淡化常規分層。我一直不提倡所謂的三層架構，什麼多層，甚至幾十層。有時候整個商務邏輯你只需要寫10行代碼，而你又被迫要在每一層寫一句代碼。汗，現在解脫了。我至今沒有見過千萬層級的項目架構都是什麼樣子的，我們做過的最大的項目不過是200-300萬，我們得到的經驗是：不走尋常路，開發簡單，維護也速度。到現在也沒有遇到一個客戶說：我心情不好，把你們現在使用的Ms sql換成mysql吧！所以在不考慮這些一直被一些人吵得火熱的靈活性可配置的情況下，我們的架構越發展越簡單，越趨向於靈活。就目前我能看到的，大部分設計都是過渡設計。沒有必要為了炫耀你的設計模式學得好，此處就非要做一個工廠！簡單的才是最好的。

         第八：許可權和菜單。我覺得毫無疑問的是，對於一個正在使用，可以被使用的架構來說，不論它怎麼分層，也不論它是輕型還是重型，無論如何它都要有自己的一套菜單和許可權管理原則。我們一直做得某些業務系統，許可權就是生命，不可馬虎。LML就提供了相應的介面，能夠方便的收集產生許可權和菜單。在介面的基礎上具體的業務系統就可以進行管理了。

         第九：自動化分頁。不可避免的分頁，也就催生了不可避免的代碼。作為一個架構師或者一個專案經理，你可以要求程式員在每一個模組中都要自行搞定分頁邏輯，大部分情況下顯示還是能夠被簡單整合的。這很不妥。LML採用的分頁將不必要重複造輪子，無論是查詢條件，還是排序，或者欄位展現，以及分頁選項，都能夠一筆帶過，輕輕鬆鬆。要的就是這個效果，有了這個誰還有必要不停地寫分頁呢。

         第十：AJAX支援。一直以來AJAX都是主流技術。壞訊息是大家都知道Struts中是不能直接存取servlet API的。好訊息是，LML支援return JSON(“”)。就這樣，完美的支援了AJAX。還可以使用return JavaScript()向頁面輸出一段可執行指令碼，你或許不瞭解他的偉大之處，我們經常用它來提示服務端校正結果，而不用重新整理頁面，更不必要驗證之後而導向另一個頁面。

         我必定是架構的作者，讓我講架構的優點，我可以講上一天一夜。

         但是，這並不是我的目的。其實我真正的目的是：樹立以簡求快的作風，讓一些人明白，對於某些需求，簡單的才是最好的。

         下集預告：架構搭建和預覽。