Midway-ModelProxy — 輕量級的介面配置建模框架
前言
使用Node做前後端分離的開發模式帶來了一些效能及開發流程上的優勢(見《前後端分離的思考與實踐 一》), 但同時也面臨不少挑戰。在淘寶複雜的業務及技術架構下，後端必須依賴Java搭建基礎架構，同時提供相關業務介面供前端使用。Node在整個環境中最重要 的工作之一就是代理這些業務介面，以方便前端(Node端和瀏覽器端)整合資料做頁面渲染。如何做好代理工作，使得前後端開發分離之後，仍然可以在流程上 無縫銜接，是我們需要考慮的問題。本文將就該問題做相關探討，並提出解決方案。
由於後端提供的介面方式可能多種多樣，同時開發人員在編寫Node端程式碼訪問這些介面的方式也有可能多種多樣。如果我們在介面訪問方式及使用上不做統一架構處理，則會帶來以下一些問題：
2. 每一個開發人員編寫自己的mock資料方式，開發完畢之後，需要手工修改程式碼移除mock。
3. 每一個開發人員為了實現介面的不同環境切換(日常，預發，線上)，可能各自維護了一些配置檔案。
4. 資料介面呼叫方式無法被各個業務model非常方便地複用。
5. 對於資料介面的描述約定散落在程式碼的各個角落，有可能跟後端人員約定的介面文件不一致。
6. 整個專案分離開發之後，對於介面的聯調或者測試迴歸成本依然很高，需要涉及到每一個介面提供者和使用者。
於是我們希望有這樣一個框架，通過該框架提供的機制去描述工程專案中依賴的所有外部介面，對他們進行統一管理，同時提供靈活的介面建模及呼叫方式， 並且提供便捷的線上環境和生產環境切換方法，使前後端開發無縫結合。ModelProxy就是滿足這樣要求的輕量級框架，它是Midway Framework 核心構件之一，也可以單獨使用。使用ModelProxy可以帶來如下優點：
2. 框架內部採用工廠+單例模式，實現介面一次配置多次複用。並且開發者可以隨意定製組裝自己的業務Model(依賴注入)。
3. 可以非常方便地實現線上，日常，預發環境的切換。
4. 內建river-mock和mockjs等mock引擎，提供mock資料非常方便。
5. 使用介面配置檔案，對介面的依賴描述做統一的管理，避免散落在各個程式碼之中。
6. 支援瀏覽器端共享Model，瀏覽器端可以使用它做前端資料渲染。整個代理過程對瀏覽器透明。
7. 介面配置檔案本身是結構化的描述文件，可以使用river工具集合，自動生成文件。也可使用它做相關自動化介面測試，使整個開發過程形成一個閉環。
ModelProxy工作原理圖及相關開發過程圖覽
在上圖中，開發者首先需要將工程專案中所有依賴的後端介面描述，按照指定的json格式，寫入interface.json配置檔案。必要時，需要 對每個介面編寫一個規則檔案，也即圖中interface rules部分。該規則檔案用於在開發階段mock資料或者在聯調階段使用River工具集去驗證介面。規則檔案的內容取決於採用哪一種mock引擎（比 如 mockjs, river-mock 等等）。配置完成之後，即可在程式碼中按照自己的需求建立自己的業務model。
下面是一個簡單的例子：
【例一】
- 第一步 在工程目錄中建立介面配置檔案interface.json, 並在其中新增主搜介面json定義
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
{ "title": "pad淘寶專案資料介面集合定義", "version": "1.0.0", "engine": "mockjs", "rulebase": "./interfaceRules/", "status": "online", "interfaces": [ { "name": "主搜尋介面", "id": "Search.getItems", "urls": { "online": "http://s.m.taobao.com/client/search.do" } } ] } |
- 第二步 在程式碼中建立並使用model
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
// 引入模組 var ModelProxy = require( 'modelproxy' ); // 全域性初始化引入介面配置檔案 （注意：初始化工作有且只有一次） ModelProxy.init( './interface.json' ); // 建立model 更多建立模式請參後文 var searchModel = new ModelProxy( { searchItems: 'Search.getItems' // 自定義方法名: 配置檔案中的定義的介面ID } ); // 使用model, 注意: 呼叫方法所需要的引數即為實際介面所需要的引數。 searchModel.searchItems( { q: 'iphone6' } ) // !注意 必須呼叫 done 方法指定回撥函式，來取得上面非同步呼叫searchItems獲得的資料! .done( function( data ) { console.log( data ); } ) .error( function( err ) { console.log( err ); } ); |
ModelProxy的功能豐富性在於它支援各種形式的profile以建立需要業務model：
- 使用介面ID建立>生成的物件會取ID最後’.’號後面的單詞作為方法名
|
1 |
ModelProxy.create( 'Search.getItem' ); |
- 使用鍵值JSON物件>自定義方法名: 介面ID
|
1 2 3 4 |
ModelProxy.create( { getName: 'Session.getUserName', getMyCarts: 'Cart.getCarts' } ); |
- 使用陣列形式>取最後 . 號後面的單詞作為方法名
下例中生成的方法呼叫名依次為: Cart_getItem, getItem, suggest, getName
|
1 |
ModelProxy.create( [ 'Cart.getItem', 'Search.getItem', 'Search.suggest', 'Session.User.getName' ] ); |
- 字首形式>所有滿足字首的介面ID會被引入物件，並取其後半部分作為方法名
|
1 |
ModelProxy.create( 'Search.*' ); |
同時，使用這些Model，你可以很輕易地實現合併請求或者依賴請求，並做相關模板渲染
【例二】 合併請求
|
1 2 3 4 5 6 7 8 9 10 |
var model = new ModelProxy( 'Search.*' ); // 合併請求 (下面呼叫的model方法除done之外，皆為配置介面id時指定) model.suggest( { q: '女' } ) .list( { keyword: 'iphone6' } ) .getNav( { key: '流行服裝' } ) .done( function( data1, data2, data3 ) { // 引數順序與方法呼叫順序一致 console.log( data1, data2, data3 ); } ); |
【例三】 依賴請求
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
var model = new ModelProxy( { getUser: 'Session.getUser', getMyOrderList: 'Order.getOrder' } ); // 先獲得使用者id，然後再根據id號獲得訂單列表 model.getUser( { sid: 'fdkaldjfgsakls0322yf8' } ) .done( function( data ) { var uid = data.uid; // 二次資料請求依賴第一次取得的id號 this.getMyOrderList( { id: uid } ) .done( function( data ) { console.log( data ); } ); } ); |
此外ModelProxy不僅在Node端可以使用，也可以在瀏覽器端使用。只需要在頁面中引入官方包提供的modelproxy-client.js即可。
【例四】瀏覽器端使用ModelProxy
|
1 2 |
<!-- 引入modelproxy模組，該模組本身是由KISSY封裝的標準模組--> <script src="modelproxy-client.js" ></script> |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
<script type="text/javascript"> KISSY.use( "modelproxy", function( S, ModelProxy ) { // !配置基礎路徑，該路徑與第二步中配置的攔截路徑一致! // 且全域性配置有且只有一次！ ModelProxy.configBase( '/model/' ); // 建立model var searchModel = ModelProxy.create( 'Search.*' ); searchModel .list( { q: 'ihpone6' } ) .list( { q: '衝鋒衣' } ) .suggest( { q: 'i' } ) .getNav( { q: '滑板' } ) .done( function( data1, data2, data3, data4 ) { console.log( { "list_ihpone6": data1, "list_衝鋒衣": data2, "suggest_i": data3, "getNav_滑板": data4 } ); } ); } ); </script> |
同時，ModelProxy可以配合Midway另一核心元件Midway-XTPL一起使用，實現資料和模板以及相關渲染過程在瀏覽器端和伺服器端的全共享。關於ModelProxy的詳細教程及文件請移步https://github.com/purejs/modelproxy
總結
ModelProxy以一種配置化的輕量級框架存在，提供友好的介面model組裝及使用方式，同時很好的解決前後端開發模式分離中的介面使用規範 問題。在整個專案開發過程中，介面始終只需要定義描述一次，前端開發人員即可引用，同時使用River工具自動生成文件，形成與後端開發人員的契約，並做 相關自動化測試，極大地優化了整個軟體工程開發過程。
【注】River 是阿里集團研發的前後端統一介面規範及相關工具集合的統稱
【附】相關文章列表
1.《前後端分離的思考與實踐（一）》
2.《前後端分離的思考與實踐（二）》