標籤：
前言鹵煮在公司之初接觸到的是一個APP應用。前端技術採用的是Backbone+zepto等小型JS類庫。在項目開發之初，這類中小型的項目採用這兩種庫可以滿足基本的需求。然而，隨著迭代的更新和業務的增加，成堆的代碼被覆蓋到項目中去了，使得這樣一種技術架構方式變得異常的臃腫，很多介面變得異常的難以維護，因此鹵煮打算重構公司前端架構。
鹵煮的想法是：採用非同步模組的載入方式，將不同菜單進入的介面分成若干的模組檔案，這樣的好處是按照需求載入介面，而且每個介面都單獨成模組，便於維護和獨立開發。於是鹵煮花了大概一個月的時間重構了前端。也就是從那時起以backbone的架構為基礎，封裝成一套組態架構。就這樣，項目經過改良，變得比較容易維護，鹵煮也從其中學到了若干經驗，積累了一些有用的代碼，最後逐步經過改進，在經過實踐的考驗（用此架構完成了其他兩個中小項目），整理成了一套自己的小型架構出來，鹵煮將之命名為SalutJs。它剛剛誕生，它並不怎麼成熟，文檔寫得比較馬虎，具體得看開發執行個體，鹵煮都放到github上去了。鹵煮用它做過三個項目，但總體感覺是比較不錯的，它非常適合做這樣的類似app中小型單頁應用。本篇博文就是向諸位分享鹵煮的一些經驗和架構知識，希望能夠協助正在最類似web應用而不知道怎麼下手的諸君一些小小的協助。
架構思路如鹵煮之前說的那樣，隨著業務和介面的增加，代碼回變得越來越難以維護。碰到此類問題，第一件想到的事情就是一個字“分”。但如何分呢？這個問題鹵煮考慮了許久。鹵煮做的開發，一個線上的點餐項目，它包含如下功能：點餐，測試人員中樞，優惠，砍價，呼叫等等十幾個，這些功能裡面，每個功能裡面進去會有相關的若干介面。可以想見，如果把所有的介面業務代碼放在一個檔案裡面，整個項目會變得異常的臃腫最後奔潰。鹵煮考慮的是將每個功能裡面的若干介面的代碼放到同一份js裡面，這樣，當使用者使用其中一個功能的時候只需要載入一個js而不是十幾個介面代碼。當我們需要從一個功能裡面的介面切換到另外一個功能模組裡面的介面時，我們運用requirejs的非同步載入方式，非同步載入需要載入的檔案。這樣便解決了代碼耦合和臃腫的問題了。值得一提的是我們結合介面的原則是根據業務需求來的。鹵煮舉個例子：在點菜功能裡面有若干介面，但點菜功能不一定會需要會員卡功能介面，所以，我們在寫點菜功能檔案的時候，是不需要把會員卡介面業務包含進去的。
html模板在渲染功能上，鹵煮沒有做何改變，沿用的是underscore的template方法渲染。由於介面的業務已經分開，那麼html結構也對應的可以分開。不必要一開始就將不必要的html代碼放入我們的主體檔案中。鹵煮載入html模板的原則是跟js有些一樣的，方法則是用ajax講html以文本的形式下載下來，然後渲染到介面中去。在require的時候，我們會去伺服器拉去對應的模板檔案，也就是說我們實現不同大功能之間的跳轉需要請求兩個檔案，一個是xx.js,另外一個是xx.html。實際開發過程中，你不需要自己去調用這些檔案，使用route.myNavigate方法，架構會自動協助你去下載js和html檔案:
目錄結構在使用Salut的時候需要按照既定的一些目錄規則來建立檔案結構。我們的項目大致分為若干目錄：
construction:設定檔以入口檔案
css：樣式檔案
fonts：字型檔
img：存放路徑
js：存放所有基礎架構js和業務代碼以及模板檔案
node：運行測試專案node檔案（實際開發中請無視）
page_main.html：主題html檔案
run.js: node檔案，運行即可將項目跑起來
js檔案夾下面又分了若干檔案夾，存放了不同的js檔案
base：salut的核心代碼
core：backbone和zepto等底層代碼
plugins：若干外掛程式
tpl：模板檔案
use：每個功能的業務代碼檔案
config：設定檔
map.html：需要用到的地圖檔案
入口：page_main.html是整個項目的html，如果沒有其他特殊的業務需求，所有的單頁面都在此html中實現，不會有url的跳轉。它的最外層是一層div包裹著的，作為最外層的容器。然後是用require引入的入口js的檔案：
<body><!-- 最外層容器 --><div id="pageWindow"></div><!-- 引入require 載入入口檔案 --><script data-main="construction/app" src="construction/require.js"></script></body>
我們看到，只要當介面一開始載入，然後開始引入了app.js檔案，在app.js中，我們會判斷當前介面的地址，配置好require的預設配置，引入自訂配置，開始拉取對應的介面業務代碼下來:
命名規則Salut的命名有自己的一套規則：主要體現在檔案命名上：在命名業務檔案上採用寫字母開頭，而在命名html檔案上規則是tp加小寫字母開頭的對應js業務檔案。在為每個節目註冊路由時，路由的名稱為大寫字母開頭，介面名則為小寫字母開頭，但名稱都是一樣的。每次你建立一個新功能的時候，必須去config裡配置這個功能模組檔案的名字和裡面對對應的介面名稱的關係，在github的例子中你會看到。這樣做的原因就是js沒有讀取本地檔案的能力，所以你必須把其他功能檔案中的介面寫在設定檔裡面，這樣，當需要去load另外一個介面的時候，才知道我們是需要載入哪一個js。
路由規則Salut並沒有改變backbone的路由規則，它沿用了之前的hash做法，在backbone源碼中，你可以看到有多種方式實現路由推動事件，他們是hash、pushstate、和定時函數。Salut的初衷也是分介面，每一個路由對應著每一個介面，在地址欄中改變hash值（#號後面那部分，對應不同介面）從而跳轉不同的介面。這個鹵煮在之前的博文中已經講到過了，這裡就不再提。路由的名稱是和介面模組的名稱有關係的，在命名規則裡面我們也已經提到過了。
總結Salut在構建類似以上提到的類似app的應用時非常適合，也非常簡單。它對於中小型的app應用來說是比較合適的。學會規則後幾乎只要簡單的配置就能完成加入一個介面到項目中的工作。鹵煮自己考慮後續把requirejs這樣的模板負載檔案替換掉（已經寫完），最後把backbone底層架構也換調，把他做成一套完全自主的js架構。不過這是一條比較漫長的道路了。鹵煮已經把相關的文檔上傳到了github上，裡面有一整套demo，注釋也寫得比較詳盡。諸君如果有興趣，請關注一下。海納百川，有容乃大。Saultjs作為初生的一套輕架構存在或多或少的問題，也由於他的實踐經驗不多，要求它不斷的在實踐中不斷地進步完善。當然，憑藉鹵煮一人之力，實在微不足道，為此特將其開源，希望諸君為它添磚加瓦，使得它更加強大。或者可以提供自己的意見，也非常歡迎貢獻代碼。總而言之，鹵煮在此並不是推廣自己的架構，只是分享一下工作中總結起來的一些代碼工具而已。如果你什麼疑問，請發郵件到[email protected]或者在部落格評論區留下你的意見，鹵煮看到後會及時回複的。
唔。。。。。淩晨一點半寫完，諸君能看到這裡給個推薦吧。
SalutJS的github地址
快速構建App介面的架構(●'?'●) -----SalutJs
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
