建站
咨詢
售后
建站咨詢
新聞中心
LML在這種情況下的夾縫中誕生。我并非高手，所以LML也不算完善。
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶，將通過(guò)不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名注冊(cè)、雅安服務(wù)器托管、營(yíng)銷軟件、網(wǎng)站建設(shè)、白銀區(qū)網(wǎng)站維護(hù)、網(wǎng)站推廣。
首先：LML基于SSH。一直以來(lái)都被公司使用的Castle框架的快速簡(jiǎn)潔而折服，在不追求運(yùn)行效率的情況下，它堪稱***，這當(dāng)然還要感謝帶它來(lái)公司的某經(jīng)理。但是，別人的終究是別人的，打心里覺得自己的才是***的。我水平有限，我沒有能力能夠在java平臺(tái)上從頭開始造一款媲美Castle的框架。站在巨人的肩膀上，很多東西就不是很復(fù)雜了。SSH是為人熟知的開源Java Web框架，成熟而又穩(wěn)定，使用率也比較靠譜，于是萌發(fā)了在SSH的基礎(chǔ)上在此封裝改造，形成一套框架的想法。
其次：LML的模板引擎使用velocity，語(yǔ)法簡(jiǎn)單，也可以很容易的借用codesmith等代碼生成工具生成模板。這實(shí)在是符合代碼簡(jiǎn)單的原則！使用velocity的另外一個(gè)原因是我們?cè)?。Net中一直使用Nvelocity，他們二者語(yǔ)法非常類似，大部分代碼幾乎可以做到無(wú)修改移植。這一點(diǎn)以后會(huì)有事例的。
第三：LML支持layout。無(wú)論是使用frame還是采用各種嵌入頁(yè)面的方式，都是為了避免重復(fù)的書寫公用的頁(yè)面，就像我們?cè)谀程幝暶髁艘粋€(gè)公用的變量，那么就不必要到處書寫公用變量所代表的值，另外也給修改帶來(lái)了方便。它其實(shí)相當(dāng)于我們?cè)赼sp.Net使用的母版。
第四：html頁(yè)面（View）直接支持調(diào)用在后臺(tái)提供的靜態(tài)或者非靜態(tài)方法。我覺得這樣也許被某些人深惡痛絕，我就曾經(jīng)被一個(gè)不知其名的小同學(xué)罵過(guò)，但是這必然是很有用的。在原始的aps.net中，我們不分什么前后臺(tái)，之后出現(xiàn)了MVC，某些人（大部分是剛?cè)腴T的吧？）一直在叫嚷視圖和邏輯分離。分離難道是絕對(duì)的嗎？個(gè)人認(rèn)為，視圖確實(shí)應(yīng)該和業(yè)務(wù)邏輯分離，而絕對(duì)不能和功能邏輯分離。業(yè)務(wù)邏輯此處是指為了實(shí)現(xiàn)一定的業(yè)務(wù)而做出的各種復(fù)雜的數(shù)據(jù)處理，功能邏輯此處是指為了展現(xiàn)數(shù)據(jù)而做的邏輯處理。我們查數(shù)據(jù)，那絕對(duì)不是目的，真正的目的是展現(xiàn)數(shù)據(jù)。就像某人懷才不遇，肚子里有千萬(wàn)數(shù)據(jù)，而不能展現(xiàn)，那還有什么用呢。我希望能夠使用更簡(jiǎn)便的方式來(lái)展現(xiàn)數(shù)據(jù)，比方更簡(jiǎn)單的循環(huán)，比方這里的我們可以直接調(diào)用后臺(tái)方法進(jìn)行簡(jiǎn)單的數(shù)據(jù)處理，已達(dá)到更***的數(shù)據(jù)展現(xiàn)。
第五：拒絕大量的配置文件。有一種思想叫做，約定優(yōu)于配置。我一直覺得SSH中需要我們配置的太多，就算一些微不足道理所當(dāng)然的也要配，簡(jiǎn)直不勝其煩。所以我大膽的做出決定如非必要，我將盡量的避免配置文件，比方我不再將Action托管給Spring。與其讓Spring采用request作用域來(lái)管理Action，還不如讓Action自生自滅的好，反正就算是托管給Spring，我也沒有見到效率更快。***的SSH支持使用注解的方式來(lái)管理配置，但是我仍覺得這沒有那么必要。所以對(duì)于一般情況，Struts的Action我使用通用配置，約定一下，什么都變得輕松了。這一切都是對(duì)我們來(lái)說(shuō)，不知道各位的情況是怎么樣子的？當(dāng)然還有一些其他的例如log4j等的配置，我也是能簡(jiǎn)就簡(jiǎn)。
第六：局限的使用Model。自從面向?qū)ο蟠笮衅涞?，漸漸深入人心，好歸好，不好的一面也影響了我們的判斷。思維固式導(dǎo)致我們要求我們只根據(jù)用戶的ID查出姓名和年齡兩列是，我們也必須要查出一個(gè)具有四十個(gè)屬性的Model列表。這，好還是不好？我們更提倡使用原生的sql去查詢，快速而有效。當(dāng)然，在編輯和保存的時(shí)候，結(jié)合struts2的自動(dòng)綁定功能，使用Model更能提高編碼效率。在使用效率一詞時(shí)，我是很謹(jǐn)慎的。這里僅僅只是編碼效率或者開發(fā)效率，至于運(yùn)行效率，一系列的綁定翻譯操作，***再執(zhí)行sql，總沒有直接執(zhí)行sql更快吧？
第七：淡化常規(guī)分層。我一直不提倡所謂的三層架構(gòu)，什么多層，甚至幾十層。有時(shí)候整個(gè)業(yè)務(wù)邏輯你只需要寫10行代碼，而你又被迫要在每一層寫一句代碼。汗，現(xiàn)在解脫了。我至今沒有見過(guò)***別的項(xiàng)目架構(gòu)都是什么樣子的，我們做過(guò)的***的項(xiàng)目不過(guò)是200-300萬(wàn)，我們得到的經(jīng)驗(yàn)是：不走尋常路，開發(fā)簡(jiǎn)單，維護(hù)也速度。到現(xiàn)在也沒有遇到一個(gè)客戶說(shuō)：我心情不好，把你們現(xiàn)在使用的Ms sql換成mysql吧！所以在不考慮這些一直被一些人吵得火熱的靈活性可配置的情況下，我們的框架越發(fā)展越簡(jiǎn)單，越趨向于靈活。就目前我能看到的，大部分設(shè)計(jì)都是過(guò)渡設(shè)計(jì)。沒有必要為了炫耀你的設(shè)計(jì)模式學(xué)得好，此處就非要做一個(gè)工廠！簡(jiǎn)單的才是***的。
第八：權(quán)限和菜單。我覺得毫無(wú)疑問的是，對(duì)于一個(gè)正在使用，可以被使用的框架來(lái)說(shuō)，不論它怎么分層，也不論它是輕型還是重型，無(wú)論如何它都要有自己的一套菜單和權(quán)限管理策略。我們一直做得某些業(yè)務(wù)系統(tǒng)，權(quán)限就是生命，不可馬虎。LML就提供了相應(yīng)的接口，能夠方便的收集生成權(quán)限和菜單。在接口的基礎(chǔ)上具體的業(yè)務(wù)系統(tǒng)就可以進(jìn)行管理了。
第九：自動(dòng)化分頁(yè)。不可避免的分頁(yè)，也就催生了不可避免的代碼。作為一個(gè)架構(gòu)師或者一個(gè)項(xiàng)目經(jīng)理，你可以要求程序員在每一個(gè)模塊中都要自行搞定分頁(yè)邏輯，大部分情況下顯示還是能夠被簡(jiǎn)單集成的。這很不妥。LML采用的分頁(yè)將不必要重復(fù)造輪子，無(wú)論是查詢條件，還是排序，或者字段展現(xiàn)，以及分頁(yè)選項(xiàng)，都能夠一筆帶過(guò)，輕輕松松。要的就是這個(gè)效果，有了這個(gè)誰(shuí)還有必要不停地寫分頁(yè)呢。
第十：AJAX支持。一直以來(lái)AJAX都是主流技術(shù)。壞消息是大家都知道Struts中是不能直接訪問servlet API的。好消息是，LML支持return JSON(“”)。就這樣，***的支持了AJAX。還可以使用return JavaScript()向頁(yè)面輸出一段可執(zhí)行腳本，你或許不了解他的偉大之處，我們經(jīng)常用它來(lái)提示服務(wù)端校驗(yàn)結(jié)果，而不用刷新頁(yè)面，更不必要驗(yàn)證之后而導(dǎo)向另一個(gè)頁(yè)面。 我必定是框架的作者，讓我講框架的優(yōu)點(diǎn)，我可以講上一天一夜。
但是，這并不是我的目的。其實(shí)我真正的目的是：樹立以簡(jiǎn)求快的作風(fēng)，讓一些人明白，對(duì)于某些需求，簡(jiǎn)單的才是***的。
原文鏈接：http://www.cnblogs.com/Bytime/archive/2012/07/23/2604364.html
網(wǎng)站標(biāo)題：以簡(jiǎn)求快Java快速開發(fā)框架LML簡(jiǎn)介
文章來(lái)源：http://www.dlmjj.cn/article/dhiggdd.html
