應用程序框架實戰二十八:前端框架決擇

　　對於BS管理系統，我很長一段時間都工做在Asp.Net Web Form上，Web Form的主要優點是可使用服務器端控件，以相似CS的開發模式進行工做，經過拖拽控件和定義事件處理函數，極大的簡化了BS的開發。服務器端控件會在渲染階段把自身輸出爲Html標籤，對咱們徹底透明，當須要設置相關屬性時，只須要在屬性面板上操做便可。

　　Web Form在誕生之時，Ajax還未流行，因此頁面的提交是徹底刷新方式。爲了記住控件的狀態，Web Form引入了ViewState和回發機制。對於一些複雜的界面，可能建立大量的服務端控件，查看ViewState序列化生成的hidden，有時候達到數百K。回發機制也讓人鬱悶，手工編寫的Js與回發機制不能很好的配合，常常發現代碼的執行時機不對。Web Form服務端控件生成的Html也至關雜亂，基本是面向機器的。

　　固然這些問題不少時候是本身的使用方式不對，不能全賴到Web Form上，但你們但願.Net可以提供更好的解決方案。

　　Ajax逐漸流行，對BS的要求大幅提高，好比局部刷新，乾淨整潔的Html等。一些 RIA框架發展起來，好比Ext、EasyUi、Dwz等。

　　微軟也推出了輕量級的Mvc框架，我是在Mvc 3 發佈時纔開始使用的，主要是被Razor視圖引擎吸引過來。爲了提高用戶體驗，還選擇了一款RIA框架，當時選擇了Dwz，主要是它開源免費，而其它框架要麼閉源，要麼收費，或者太複雜了，學習成本高。

　　在使用了幾年Dwz以後，最近決定更換一個前端框架，下面談談使用Dwz的一些狀況。

　　Dwz做爲一款國產免費的開源框架是值得支持的，官網http://www.j-ui.com。經過Dwz，我學習到大量Js和Css的相關知識，在此表示感謝。

　　Dwz基於JQuery，設計以Html擴展爲主，對SPA (single page applications, 單頁應用程序)有很好的支持，API命名規範，代碼質量較高。

　　使用中碰到的問題也很多，首先是缺少專業的文檔，官方只提供了一個很簡單的使用手冊，每當碰到問題，我老是進入dwz源碼斷點調試，不過這樣更能深刻學習內部機制，彷佛也不算嚴重的缺點。

　　從我開始使用Dwz，好像就沒見更新過。

　　Dwz有些組件不夠完善，好比彈出模態窗口，只支持彈出一層，若是在彈出的模態窗口上繼續彈出模態窗就不支持了，而這屬於經常使用功能，對於這些小功能，我本身修改，咬咬牙也仍是能夠搞出來。

　　對於一些重量級的組件，好比表格、樹等，Dwz提供的比較弱，我通常都引入第三方插件，好比ZTree。

　　還有一個頭痛的問題是佈局，Dwz沒有提供border或fit這樣易用的佈局方式，除了面板和Tabs等常規佈局組件外，只有一個神祕的layoutH屬性，它的值是一個數字，表示工具欄的高度，對於一個複雜點的佈局，我常常東調西試以找出這個正確的數字。固然這也只能怪我水平有限，掌握不夠好，因此引入一個更強大的前端框架就迫在眉睫。

　　對於大名鼎鼎的Ext，我已經關注它很長時間，不過一直沒敢使用它，有幾個緣由。使用純Js開發界面，有點違反通常程序員的習慣，大部分程序員仍是喜歡用Html佈局。另外一個緣由是面向對象的Js要求比較高，API豐富而龐大，學習成本高。固然最重要的一個緣由是，對於管理後臺這樣的系統，大量手寫Js開發效率低，且Js是弱類型語言，代碼提示很弱，且沒有編譯時檢查，容易出錯，健壯性差。因此哪怕要使用Ext，我也會用C#來包裝一次，這個工做已經有人作了，這就是Ext.Net。十分遺憾的是，Ext.Net不是開源的，並且還收費，它甚至把js等資源內嵌到dll中，另外還不支持DataAnnotations驗證，這讓我打消了使用它的念頭。

　　Ext也是要收費的，但有一個版本2.0.2能夠無償使用，個人想法是，若是作小項目，就用高版本，偷偷的用估計也沒人知道，若是須要公開使用，就切換到2.0.2這個版本。經過C#建立一個抽象機制，不只能夠簡化開發，並且能夠方便切換版本。我在嘗試了一段時間後，發現封裝的工做量很大，因此暫停了，待之後確實須要的時候再繼續。

　　目光轉到EasyUi，EasyUi傳說也是國人開發的，不過其官網倒是純英文。對於EasyUi，我幾年前也曾瞭解過，當時認爲沒有源碼，萬一出現bug不是束手就擒嗎。雖然如此，我卻發現它愈來愈流行了，博客園搞框架的十有八九都是用的EasyUi，周邊也有不少公司在使用，甚至在招聘要求上，我也看到過要求有EasyUi的經驗。這說明EasyUi的穩定性仍是有保證的，你們用都沒問題，難道個人運氣就那麼背。

　　除了跟風之外，我選擇EasyUi還有幾個重要緣由，首先是功能比較強大，重要的複雜組件和佈局組件都提供了，雖然沒有Ext那麼完善，但也基本夠用。其次是學習成本低，EasyUi也是基於jQuery，並且支持Html擴展。最後是官方文檔比較齊全。

　　能夠看到，EasyUi的功能、文檔、易用性等介於Dwz與Ext之間。

　　還有一些朋友給我強力推薦Bootstrap，不過我感受它有點輕量，管理系統須要更重口味的框架，開發相似會員後臺的時候再考慮採用Bootstrap。

　　我學習EasyUi還不到一個月，不少東西仍處於摸索中，EasyUi雖然比較強大，但仍是發現很多問題。

　　首先是它的方法調用方式讓人很鬱悶。好比我如今要關閉一個窗口，須要這樣調用$('#xxx').dialog('close')，爲何不能這樣調用$('#xxx'). close ()。還好我主要使用Html擴展方式，手工編寫Js僅用來處理回調，這個問題能夠忍忍。

　　其次發現很多小bug，好比多行文本框沒法回車換行，時間控件在某些時候點擊時報對象爲null的錯誤等等，我使用的是IE 11，估計做者尚未對IE 11進行全面測試，但願能及時更新。

　　EasyUi雖然是一個比較完善的前端框架，但並不意味着不須要花任何力氣，你就能夠開發出健壯的應用。下面討論兩個重要的設計決策。

SPA仍是IFrame

　　SPA，全稱Single Page Applications, 即單頁應用程序。它的設計理念是僅在主框架界面使用一個完整的Html頁面，其它全部內容頁面都是Html片段，沒有html、head、body這些標籤，主框架界面經過ajax的方式加載內容頁面。

　　SPA是正宗的Ajax應用模式，而且逐步成爲Ajax應用的趨勢。它的優勢顯而易見，全部東西都在同一個頁面，查找任何元素，直接用jQuery選擇器就好了。

　　任何事物都有兩面性，SPA也有不少缺點，最嚴重是命名衝突和兼容性。

　　對於同一個Html頁面，若是兩個元素的id出現重複，當你用css選擇器進行格式化，或用jQuery選擇器對其操做時，就會發生意想不到的狀況。你會發現，操做某個內容頁面時，竟然影響到另一個不相干的內容頁。

　　jQuery解決這種命名衝突，是經過傳入一個額外的上下文對象，好比$(「#xx」,context)。Context表明某個內容頁，這樣就能夠僅查找該內容頁的id，從而消除了命名衝突。

　　對於SPA，Dwz提供了自然的支持，它封裝了CRUD相關的全部操做，並提供了一個當前上下文context來保存當前操做的內容頁或彈出窗口。

　　雖然Dwz提供了SPA支持，但我在使用中，依然發現偶爾出現各內容頁互相影響的狀況，爲了防止命名衝突，我將id命名得很複雜，以減小衝突。

　　再看EasyUi，對於CRUD操做，只在官網找到一個很簡陋的Demo。仔細研究了Tabs等組件後，感受EasyUi默認支持的是SPA模式，由於這些組件都沒有對IFrame進行支持。EasyUi既然支持的是SPA模式，但卻沒有作進一步的封裝，能夠判定，以SPA模式使用EasyUi，命名衝突是比較嚴重的。

　　還有一個頭痛的問題是兼容性，因爲全部內容頁面在同一個Html中，若是某些頁面須要引用一個第三方插件，而這個插件不是基於jQuery的，或者jQuery版本不一樣，引入這些插件可能失敗。

　　基於以往的經驗，我決定不在管理系統這種複雜的應用中使用SPA，而是使用IFrame的方式加載內容頁。

　　因爲EasyUi沒有對IFrame提供支持，當我向主界面的Tabs引入IFrame後，引起了一大堆連鎖問題，我花了大把時間終於把這些問題解決了，後面將用專門的文章來介紹碰到的障礙。

封裝有無必要

　　大部分使用Mvc的朋友，都是從Web Form轉過來的。所謂一遭被蛇咬，十年怕井繩，因爲在Web Form上吃過過分封裝的苦頭，來到輕量級的Mvc世界，他們懼怕服務器端的任何東西，只敢使用原生的html和js了。

　　Mvc提供了一套Html表單控件的封裝，好比文本框，@Html.TextBox( "id" )，它等價於<input type="text" name="id"/>。從這個簡單的例子，好像使用服務器端語法優點並不明顯。但值得注意的是，服務器端語法可以將DataAnnotations驗證自動轉化爲jQuery驗證，這一點仍是比較強大的。

　　對於簡單的html標籤，你是否使用mvc的服務端語法不是特別重要，但對於像Dwz或EasyUi這種Html擴展爲主的前端框架就很是必要了。

　　EasyUi將每一個組件的屬性都擴展到了Html標籤上，對於Html標籤，你還能期望代碼提示嗎？沒有代碼提示，就意味着你得隨時打開EasyUi的官網，以複製相關的屬性。固然你不少時候會本身手工輸入，你必須把這些API記得很是精確，若是多一個或少一個字符，你就會獲得錯誤的結果。若是你沒有遵循敏捷開發的小步前進，而是把整個頁面輸入完成纔開始運行，在密密麻麻的Html標籤中找出輸入錯誤的屬性也不是一件容易的事。

　　若是把EasyUi的屬性用C#封裝起來，由C#來輸出Html標籤，你就能夠徹底再也不操心API的問題，全部的API只需在代碼提示中上下移動便可。能夠看到，Web Form的不少思想實際上是很是好的，好比用服務端代碼輸出客戶端代碼，你應該去其糟粕，取其精華。

　　對前端框架的封裝，真正強大的地方來自Lambda表達式。

　　從Lambda表達式中，你能夠獲取到一些元數據信息，好比name、value、驗證信息，一個簡單的操做@Html.EasyUi().TextBox( t => t.Name )，可能設置了10幾個屬性，而且全部的屬性均來自服務器端，這樣維護也更加方便了，你不用來回修改客戶端代碼。

　　Lambda表達式還能夠獲取到屬性的類型，這有什麼用呢？當你寫上一句@Html.EasyUi().TextBox( t => t.XXX )，若是XXX是整型，文本框就自動轉成EasyUi的數字文本框，只能輸入數字，若是它是一個日期，文本框就顯示成一個日期控件。再好比@Html.EasyUi().Combox( t => t.XXX )，當它是布爾類型，就顯示一個是、否的下拉列表，若是它是一個枚舉就自動綁定一個枚舉值的下拉列表，這是否是比你手工輸入要強些呢。

結語

　　本文簡要介紹了我對幾個前端框架的認識，也說明了封裝的必要性。

　　因爲我也是EasyUi初學者，我提供的Demo並非一個能夠直接使用的框架，不過做爲學習範例，你能夠把它做爲你的應用程序框架的起點。

　　我後續文章會逐步介紹Demo中各構造塊的封裝和使用要點，全部代碼以我最新發放的Demo爲準。

　　爲了避免沖淡本系列主題，我會專門爲EasyUi框架的封裝建立一個系列。

　　對於EasyUi的封裝，我並沒打算封裝它的所有內容，畢竟我不是靠這個吃飯的，我僅在開發時碰到需求才會進行擴展，個人Demo會隨着個人開發逐步加強，我會按期發放最新源碼。

　　Demo已更新，須要的老規矩，點推薦，留Email，本次截止2015年1月28日15點。

　　另外你們短期沒收到源碼不要着急，只要在規定時間內均可以拿到。

 

　　.Net應用程序框架交流QQ羣: 386092459，歡迎有興趣的朋友加入討論。

　　謝謝你們的持續關注，個人博客地址：http://www.cnblogs.com/xiadao521/