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

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

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

第三：LML支持layout。無論是使用frame還是采用各種嵌入頁面的方式，都是為了避免重復(fù)的書寫公用的頁面，就像我們在某處聲明了一個公用的變量，那么就不必要到處書寫公用變量所代表的值，另外也給修改帶來了方便。它其實(shí)相當(dāng)于我們在asp.Net使用的母版。         

第四：html頁面（View）直接支持調(diào)用在后臺提供的靜態(tài)或者非靜態(tài)方法。我覺得這樣也許被某些人深惡痛絕，我就曾經(jīng)被一個不知其名的小同學(xué)罵過，但是這必然是很有用的。在原始的aps.net中，我們不分什么前后臺，之后出現(xiàn)了MVC，某些人（大部分是剛?cè)腴T的吧？）一直在叫嚷視圖和邏輯分離。分離難道是絕對的嗎？個人認(rèn)為，視圖確實(shí)應(yīng)該和業(yè)務(wù)邏輯分離，而絕對不能和功能邏輯分離。業(yè)務(wù)邏輯此處是指為了實(shí)現(xiàn)一定的業(yè)務(wù)而做出的各種復(fù)雜的數(shù)據(jù)處理，功能邏輯此處是指為了展現(xiàn)數(shù)據(jù)而做的邏輯處理。我們查數(shù)據(jù)，那絕對不是目的，真正的目的是展現(xiàn)數(shù)據(jù)。就像某人懷才不遇，肚子里有千萬數(shù)據(jù)，而不能展現(xiàn)，那還有什么用呢。我希望能夠使用更簡便的方式來展現(xiàn)數(shù)據(jù)，比方更簡單的循環(huán)，比方這里的我們可以直接調(diào)用后臺方法進(jìn)行簡單的數(shù)據(jù)處理，已達(dá)到更***的數(shù)據(jù)展現(xiàn)。       

 第五：拒絕大量的配置文件。有一種思想叫做，約定優(yōu)于配置。我一直覺得SSH中需要我們配置的太多，就算一些微不足道理所當(dāng)然的也要配，簡直不勝其煩。所以我大膽的做出決定如非必要，我將盡量的避免配置文件，比方我不再將Action托管給Spring。與其讓Spring采用request作用域來管理Action，還不如讓Action自生自滅的好，反正就算是托管給Spring，我也沒有見到效率更快。***的SSH支持使用注解的方式來管理配置，但是我仍覺得這沒有那么必要。所以對于一般情況，Struts的Action我使用通用配置，約定一下，什么都變得輕松了。這一切都是對我們來說，不知道各位的情況是怎么樣子的？當(dāng)然還有一些其他的例如log4j等的配置，我也是能簡就簡。         

第六：局限的使用Model。自從面向?qū)ο蟠笮衅涞?，漸漸深入人心，好歸好，不好的一面也影響了我們的判斷。思維固式導(dǎo)致我們要求我們只根據(jù)用戶的ID查出姓名和年齡兩列是，我們也必須要查出一個具有四十個屬性的Model列表。這，好還是不好？我們更提倡使用原生的sql去查詢，快速而有效。當(dāng)然，在編輯和保存的時候，結(jié)合struts2的自動綁定功能，使用Model更能提高編碼效率。在使用效率一詞時，我是很謹(jǐn)慎的。這里僅僅只是編碼效率或者開發(fā)效率，至于運(yùn)行效率，一系列的綁定翻譯操作，***再執(zhí)行sql，總沒有直接執(zhí)行sql更快吧？         

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

 第八：權(quán)限和菜單。我覺得毫無疑問的是，對于一個正在使用，可以被使用的框架來說，不論它怎么分層，也不論它是輕型還是重型，無論如何它都要有自己的一套菜單和權(quán)限管理策略。我們一直做得某些業(yè)務(wù)系統(tǒng)，權(quán)限就是生命，不可馬虎。LML就提供了相應(yīng)的接口，能夠方便的收集生成權(quán)限和菜單。在接口的基礎(chǔ)上具體的業(yè)務(wù)系統(tǒng)就可以進(jìn)行管理了。         

第九：自動化分頁。不可避免的分頁，也就催生了不可避免的代碼。作為一個架構(gòu)師或者一個項目經(jīng)理，你可以要求程序員在每一個模塊中都要自行搞定分頁邏輯，大部分情況下顯示還是能夠被簡單集成的。這很不妥。LML采用的分頁將不必要重復(fù)造輪子，無論是查詢條件，還是排序，或者字段展現(xiàn)，以及分頁選項，都能夠一筆帶過，輕輕松松。要的就是這個效果，有了這個誰還有必要不停地寫分頁呢。         

第十：AJAX支持。一直以來AJAX都是主流技術(shù)。壞消息是大家都知道Struts中是不能直接訪問servlet API的。好消息是，LML支持return JSON(“”)。就這樣，***的支持了AJAX。還可以使用return JavaScript()向頁面輸出一段可執(zhí)行腳本，你或許不了解他的偉大之處，我們經(jīng)常用它來提示服務(wù)端校驗(yàn)結(jié)果，而不用刷新頁面，更不必要驗(yàn)證之后而導(dǎo)向另一個頁面。         我必定是框架的作者，讓我講框架的優(yōu)點(diǎn)，我可以講上一天一夜。         

但是，這并不是我的目的。其實(shí)我真正的目的是：樹立以簡求快的作風(fēng)，讓一些人明白，對于某些需求，簡單的才是***的。

原文鏈接：http://www.cnblogs.com/Bytime/archive/2012/07/23/2604364.html

【編輯推薦】

1. Java8 和 Scala 中的高階函數(shù)
2. Java8和Scala中的Lambda表達(dá)式
3. Java SE引路蜂地圖開發(fā)示例
4. 中軟國際Java程序員筆試題
5. Java 8的Lambda表達(dá)式