關於互聯網應用前端架構的一些思考

1、互聯網應用的分類

討論前端架構以前，首先要弄清楚互聯網應用的類型，明確了本身的產品所屬的類型才能打造屬於本身的架構。對互聯網產品進行分類，網上有不少不一樣的觀點。我以爲分類是多維度的，可是按照交互以及功能的複雜程度來分類是比較客觀的。所以，我比較認同淘寶玉伯在關於先後端開發模式中對應用的分類，如下引用玉伯的觀點：

前端涉及的產品形態在業界可分爲兩大類：Web Pages 和 Web Apps 。

Web Pages 是瀏覽類的，用戶主要是來看的：之內容展示爲主，輔有少許交互。前端提供基礎類庫，開發工具化、外包化。典型：首頁、營銷活動、頻道等等。

Web Apps 則以交互爲主，用戶主要是來用的。可分爲兩種：

• 體驗類：包含大量交互，同時用戶體驗很重要。好比 GMail, 支付寶收銀臺、淘寶購物車等等。
• 功能類：包含大量交互，以功能爲主，體驗不是第一位的。好比後臺系統、認證流程等。

1. Web Apps 的開發，前端投入了大量人力，但前端資源依舊存在潛在的瓶頸（好比新增長一條業務線時，極可能無前端去支持）。現有先後端配合的開發模式，溝通協做成本偏高，可維護性不夠方便。在現有的研發模式下，前端自身的價值點也很難體現出來（花了大量時間在業務上，但獲得的承認很少）。
2. 最核心的問題，依舊是先後端的解耦：如何讓先後端的工做彼此更獨立，如何讓更合適的人作更合適的事，把事情作得更好。
3. 對於體驗類，目前業界有不少新興的解決方案：Backbone, Ember, Knockout 等等，包括 YUI 的 App framework 等。這些解決方案，都但願後端專一於提供 REST 接口，其餘的都交給前端來搞定。
4. 對於功能類的，目前業界解決方案依舊是比較老的一套，好比 GWT 等，包括 ExtJS 也是但願能讓後端搞定一切。

2、體驗類應用在架構層面要解決的問題

咱們知道了本身的產品所屬的類型，也知道了每一種類型業界已有的一些解決方案。是否是引入這些成熟的解決方案就能夠了？實際的應用場景要複雜不少。要知道任何一個開源框架都有他的適用範圍，不可能跟本身的應用100%匹配。舉例說明，如下這些通信層的需求是比較常見的：

（1）統一攔截http請求，轉換請求報文格式（json轉xml等）

（2）接口超時或者異常則上報日誌

（3）統一攔截http響應，非法JSON解析異常進行日誌上報，轉換響應報文的數據格式（xml轉json等）

（4）添加統一的請求頭部

（5）html5分塊上傳的特殊處理

若是咱們的MVC框架選型爲backbone，要知足這些需求咱們不得不去修改backbone的通信層源碼（你會發現backbone的通信層實際上是對jquery的ajax方法的又一次封裝）。若是這種需求場景過多，咱們就得頻繁的修改源碼，最終代碼將變得難以維護。引入框架必將失去一部分靈活性，這是代價。記得不久前，在infoq上看過一個facebook的前端工程師的視頻，他對前端趨勢的部分觀點，我比較認同：前端將來的趨勢應該是去框架化。每一個公司都應該根據本身的產品類型，打造屬於本身的框架。固然在這個過程當中咱們能夠吸收優秀框架的思想，甚至對開源框架進行必要的裁剪，複用核心功能。在架構層面咱們一般至少要解決如下問題：

一、模塊化

二、視圖與數據解耦

三、視圖與視圖解耦

四、健壯的通信層

五、DOM操做

六、工具庫

七、業務層代碼的水平拓展

八、減小重複代碼

九、靜態資源的版本管理

十、語法檢查、自動打包

 

3、爲體驗類應用打造框架

（1）模塊化。AMD（require.js、curl.js）、引入命名空間

（2）視圖與數據解耦，可引入模板引擎好比：underscore的template、jquery Template、自定義模板引擎（139郵箱的Repeater）

（3）試圖與視圖解耦，可引入backbone的事件機制，使用trigger、on切斷視圖之間的直接調用

（4）健壯的通信層，建議本身封裝通信層。通信層須要具有如下功能：

　　一、路由功能。接口可配置，業務層只需傳遞接口名稱便可獲取接口絕對路徑，併發送ajax請求，是否須要跨域由通信層自行解決。

　　二、攔截請求，統一設置請求頭部，將報文轉換爲接口須要的數據格式

　　三、容錯能力。設置超時時間避免瀏覽器鎖死。捕獲error事件，並上報日誌

　　四、攔截響應，校驗接口返回的數據格式，報錯則上報日誌。

（5）DOM操做。引入開源JS庫，jQuery當仁不讓。

（6）工具庫。underscore、自定義業務工具庫（手機號碼加8六、郵件地址解析手機號碼等）

（7）業務層代碼的水平拓展。新增需求，只需按照規範建立視圖層與模型層，根據須要調用公共組件便可完成交互

（8）減小重複代碼。抽象各業務模塊的共性，組件化，業務層只需調用組件專一於業務，遵循職責單一的編碼原則，從而提升代碼的複用率。

（9）靜態資源的版本管理。可爲每個文件生成MD5值，頁面引入靜態文件時URL後加上MD5值，文件有更新只需從新生成MD5值便可。

（10）持續構建。語法檢查、自動打包。可採用ant調用jar包（jslint、compiler.jar）

 

近期我會分別整理出每一環節的部分源碼。

 

4、參考資料

http://www.infoq.com/cn/interviews/trend-of-without-framework

http://www.infoq.com/cn/news/2012/06/web-front-back-development/