我的架構經驗系列文章-前端架構

回到索引 http://www.cnblogs.com/lovecindywang/archive/2012/12/23/2829828.html

框架層面：

近幾年前端發展很快，前端之所以叫前端因為前端是已經可以獨立成為一種職業了，js也不再是十年前的玩具了，以前富客戶端RIA的應用可能會用flash/flex或是silverlight，現在可以使用js來完成大部分的功能，因此js作為一門前端的支撐語言也不僅僅是進行的簡單的編碼，越來越多框架性的東西出現了。越來越多的開發模式轉變為後端只是吐json的資料來源，而前端做所有UI的事情。

• MVC

MVC實現職責分離是很好的，大多數網站在後端都會引入MVC框架，對於一個前端負責所有呈現和前端業務邏輯的網站來說，使用MVC框架也是很有好處的。Javascript的MVC框架現在很多，http://www.infoq.com/cn/news/2012/05/js-mvc-framework。每一個框架其實都有其特點的，但是前端的MVC框架會和後端的有些不同的。比如前端的MVC框架可能會做一些M和V元素的雙向繫結，對於後端來說往往是單向的比較多。通過引入MVC框架我們可以讓同一個頁面做很多事情，通過一個不重新整理的頁面實現一個應用程式的根基，還可以很清晰地進行MVC的分離並且突出M的概念，這是沒有框架所辦不到的。

• 通訊

對於一個比較複雜的頁面可能會有比較多的Javascript模組，如果要進行模組之間通訊的話（比如一個頁面有左邊選單和導航以及列表，左邊選單點選一級分類之後要通知導航加上去這項，並且通知列表重新讀取資料並重新整理，然後從導航刪除這個選擇的話要通知列表重新獲取資料，通知選單顯示所有）。對於比較複雜的通訊，如果把模組模組之間進行強耦合直接呼叫其它模組的函式的話是不利於可維護性的，我覺得可以引入釋出訂閱機制，每一個模組做了什麼修改把資訊釋出出去，關心這個資訊的人訂閱這個資訊，並且在回撥函式裡面做相應的操作就可以了。可以使用Amplifyjs作為釋出訂閱的框架。

• 模板

對於前端來說和後端一樣一個比較麻煩的問題就是往往會在指令碼里面把html也混在一起，個人覺得是這樣的，如果對於非常瑣碎一些dom修改問題倒不大，如果是大塊的html拼接的話，資料和html甚至是css混合在一起，那麼程式碼的可維護程度非常差。此時可以考慮使用一些模板引擎來分離資料和表現，比如Twitter hoganjs。由於很多模板引擎，比如大鬍子引擎不僅僅是針對前端的，後端語言也有相應的引擎，因此甚至可以把模板放在文字檔案中，前端後端共同使用一套模板引擎，也就是說現在的程式碼偏向於服務端渲染的那麼就在後端使用模板，如果要以後改為客戶端渲染了這套模板可以直接被前端使用。

• 類庫

除了框架之外還有很多類庫，比如jquery，underscore，linq.js（linq to javascript），jscex（wind）反正後端有啥現在前端也有啥，盡情發揮想象吧。用好這些框架可以大大改善生產力的，指令碼能做的事情真的比想象的要多的多。我是做後端的前端知道的不多在這裡列出的可能只是九牛一毛。

• 依賴

可以使用Requirejs、Commonjs之類的元件來管理指令碼之間的依賴，好處很多的，我們的模組只需要寫清楚需要依賴什麼，Requirejs自然會幫我們按照一定的次序載入進來，這樣我們既不用擔心順序問題也不用擔心元件的版本號問題。基於Requirejs它具有豐富的配置，即使是我們進行了靜態資源合併也完全能處理，只要通過配置把元件配置到相同的服務端生成的一個路徑上即可，不過以前在做的時候發現它會自動加上.js 副檔名，不過完全可以通過改Requirejs原始碼解決。在架構上我的觀點是既然使用開源的東西，遇到問題了就不要去怕改原始碼。我們一定不能停留在框架的使用者，定製框架甚至向作者貢獻自己的程式碼沒有這麼難。

設計層面：

• 職責分離的理念

雖然我們都知道CSS樣式、JS行為以及HTML結構。個人覺得只有HTML是必須的，也就是說如果一個頁面沒有樣式沒有指令碼的話它應該是一個清晰的頁面，可以大致表現出頁面需要表現的內容，只不過樣子比較難看，並且也是互動的。如果說很多功能是ajax實現的話那麼就把互動工作轉到服務端實現服務端的渲染。多了樣式只是佈局上樣子上更好看，多了指令碼只是互動性上更友好，不需要重新整理頁面，但是少了也不代表這個網站就是廢物了，現在有很多理念其實目的是一樣的。如果達不到這個境界至少我們要很明確的讓css、js和html履行自己的職責，不要把過多的事情賦予不相關的元件。比如儘量不要在html中包含操作性的指令碼程式碼，而是應該直接在指令碼中選擇dom元素進行操作，儘量不要在指令碼中包含大段的html程式碼而是應該從模板讀取然後把資料填充進去，也儘量不要在html程式碼中包含大量內嵌的樣式而是應該通過選擇器選擇進行樣式賦值。

• 分層和目錄結構

對於一個比較複雜的大型的專案，合理規劃目錄結構也是很重要的，你可能會說指令碼和樣式分兩個目錄就可以了，但是如果一個複雜的專案有幾百個指令碼都列在一個資料夾下嗎？後端有分層的概念其實前端完全也可以有分層的概念，有表現層、業務邏輯層和模型層，然後是下面的資料訪問ajax層，當然還會有常量的檔案，我反問覺得前端的分層可以超大型專案的ios或android程式來靠。比如之前我做的一個ios程式的示例http://www.cnblogs.com/lovecindywang/archive/2012/09/11/2680055.html個人覺得這樣的分層就比較一目瞭然的。

• 合併和拆分的平衡

很多時候架構上的東西就是一種權衡，如果有固定的標準的話也就不需要架構師了，我們只需要按照固定的標準去做就行了。比如，一個頁面上使用了10個指令碼檔案，5個樣式檔案，按道理說合併成兩個檔案可以達到最小的請求數，但這樣一定是好的嗎？這個10個指令碼和5個樣式檔案中有很多或許是其它頁面也需要公用的，如果僅僅簡單的合併在一起反而可能增加使用者的下載流量，因此怎麼規劃通用的東西合成一個檔案，框架的檔案單獨，而每一個頁面都有自己獨特的指令碼和樣式，也是一種學問。

效能層面：

• 效能檢測

諸如YSlow和PageSpeed等工具可以分析出前端的效能問題，在這裡就不展開討論了。對於前端來說由於涉及到使用者的客戶端環境和網路環境所以情況不是這麼單純，但是我們可以做到的就是在我們的可控範圍之內儘量減少使用者域名解析數量，減少使用者下載的資料量，增加併發等等。其實說白了，我們就是清理管道使得管道更大，或者增加更多的管道，或者就是儘量讓管道之內的水少一點了，這樣就可以更順暢。

• 效能分析

現在有一些工具可以對Javascript的效能甚至是DOM解析的情況進行細緻的分析，比如dynaTrace AJAX Edition，通過這樣的工具我們可以分析我們的指令碼程式碼以及頁面佈局是否合理，從開發的角度來全面瞭解和優化我們的前端程式碼。客戶端的資源雖然不像服務端的資源這麼重要，但是為了給使用者的機制體驗最好還是對客戶端的效能消耗有所優化。