React Native: 三層架構模型

React Native解決了H5的性能問題，Weex本質上也是React Native，發展很是迅速，目前有替代原生開發的趨勢。本人本來是iOS Native開發的堅決支持者，本來打算從Objective-C過渡到Swift，就像在Windows平臺跟着微軟走同樣省心省力。無奈形式比人強，省錢省人工對企業由足夠的吸引力，養家餬口是現實需求，情懷不能當飯吃，因此做爲前端，仍是要跟上時代步伐，多學一門技術。
在iOS Native開發中，View Controller不容易複用，代碼又集中，因此不少聰明人想出了MVVM等架構模型來給View Controller減負。在React Native中，發現這種優點自然存在，好比有一個this.state，自然有界面觀察者的做用，只要調用this.setState，就能更新界面，這個至關於View Model的做用了。在iOS Native開發中，須要自定義一個View Model結構體，並用上屬性觀察者這種特性，Swift纔有，才能達到相似效果。
ES6以後，JavaScript引入了class關鍵字，面向對象的編程方法用起來就方便多了。同時，還有Promise和async/await，函數式編程的想法也很流行。因爲本人iOS Native的編程時間更長，因此很天然地想把MVVM這種想法帶過來，造成一個三層架構模型。

簡介

簡單講，就是將原來React Native中一個registerComponent，至關於View Controller，能作完的事情，分爲功能，邏輯，頁面三層。將原來一個js文件能搞定的事情分散到3~4個不一樣的js文件中。

 

三層文件夾.png

• userInterface 用戶界面層，這部分按照React Native來劃分子模塊。這裏模塊劃分的標準是一張的的頁面，複用的思路是組件。

• businessObject業務對象層。這是業務邏輯層，按照面向對象的方法劃分子模塊，是一個個具體的業務概念，好比信息採集，貸款申請，我的信息管理等。

• functionModule函數模塊層。這是基礎函數功能模塊，按照函數式編程的思想劃分子模塊，是一個個具體的功能函數，好比網絡取數據，緩存操做等等。

用戶界面層

 

用戶對象層.png

• page：這個表明一個個的頁面，通常都是一個registerComponent處理過的，是最頂層的發起者。

• component：這是可複用的組件。這是React Native的核心思想，框架自己也已經提供了足夠豐富的組件供使用。固然這裏主要的是對基礎組件進行自定義組合，方便page：中的頁面調用。

• image：這是靜態資源，好比圖片等

• constant：這是常數集中定義的地方，好比界面共用的顏色，字體，尺寸，文字等等

這一層的主要工做就是集中精力把界面渲染出來，具體的功能和業務儘可能都分出去。好比，設置頁面標題，雖然很簡單，也經過調用下面的邏輯層來實現，不須要本身作。

業務對象層

 

業務對象層.png

• service：這是公共服務對象，通常以單例的方式提供。好比頁面跳轉，主要是url的定義，能夠集中寫在這裏。好比本地緩存，最主要的是key值的定義，能夠集中寫在一個文件中。好比遠程網絡訪問，主要是一些url和參數的定義，能夠集中寫在一塊兒。

• personal, enterprise：這個按照具體的業務劃分。好比，這裏是企業業務和我的業務來劃分文件夾的。

• Business：這個名字能夠固定，固然也能夠用其餘名字。他的做用是承接頁面分出來的工做。打個比方，頁面page就像總裁，只要發號施令就能夠了，好比響應保存按鈕，處理文字錄入等等；Business：就像是頁面這個總裁的助理，將全部業務都接過來，找人完成。

• ViewModel：這個是用來替代this.state的，主要保存頁面須要展現的信息。須要更新的話，頁面調用一下this.setState({});就能夠了。相對於this.state，這個已經夠好了，他的好處是能夠把字段定義從頁面中分離出來，而且能夠用類的方式，將字段定義的更清晰，還能夠提供處理函數，作一些頁面邏輯工做。好比，把姓和名拼接成一個字段等。接上面的比方，ViewModel：就至關於Business：這個助理，根據page總裁的指令，給出的具體工做成果。

• Model：這個通常對應於網絡返回數據。JavaScript的網絡傳輸返回的就是對象，字段還能夠隨時添加，很是靈活。不過沒有名字，用起來跟dictionary也差很少，key基本靠猜。Model：能夠用類來定義，讓你們有一個共同的地方來看字段定義。固然，類能夠有成員函數，提供必定的數據處理能力。

• Business：是按照業務邏輯來分的，跟頁面的劃分標準都不同，因此Business和page之間並無一一對應的要求。好比，這裏的Business：就爲三個頁面服務，搜索、信息輸入、地址選擇三個page共用。若是作成單例的話，還能夠用成員變量保存狀態，省去了頁面之間傳遞數據的麻煩。

• ViewModel：通常是跟具體的page一一對應的，由於這個自己定位就是相關page顯示需求。固然，對於一些比較複雜的page，可能須要多個ViewModel：來共同服務。

• Model：通常跟具體的網絡請求或者緩存對象對應，由Business：來複雜持有和管理。對於page來講是不可見的。page這個總裁只關心須要顯示的ViewModel這種看得見的工做成果，至於實際上究竟是誰作的，具體怎麼作的，只要助理Business清楚就能夠了，他做爲老總，沒有必要知道。

函數模塊層

 

函數功能層.png

• 這一層是按照函數式的編程思想來作的。對外提供的是一個個可以工做的函數。好比對話框，照相，網絡訪問，事件，路由等等。

 1 async function actionSheet(title = '標題',
 2                            buttons = ['第一個按鈕', '第二個按鈕', '第三個按鈕'],
 3                            cancelButtonText = '取消',
 4                            destructiveBtnIndex = -1) {
 5     return new Promise((resolve, reject) => {
 6         AlipayJSBridge.call('actionSheet',{
 7             'title': title,
 8             'btns': buttons,
 9             'cancelBtn': cancelButtonText,
10             'destructiveBtnIndex': destructiveBtnIndex,    // 變紅按鈕的index
11         }, data => {
12             const index = data.index;
13             const cancelIndex = buttons.length;
14             if (index < cancelIndex) {
15                 return resolve(index);
16             } else {
17                 return reject('選擇了取消按鈕');
18             }
19         });
20     });
21 }
22 
23 export {
24     actionSheet,
25 };

好比這個是iOS開發中常見的action sheet，通常是Native實現，而後提供調用接口。這個是等待用戶選擇，而後根據選擇結果進行相應處理。Native是以回調函數callback來實現異步過程的，在這裏用了JavaScript的Promise包裝，就能夠在後續調用中使用async/await這種最新科技了。

• 爲了方便使用，將輸出接口在一個彙總文件中集中一下是個值得推薦的作法。好比:

 1 export {
 2     showLoading,
 3     hideLoading,
 4 } from './Loading';
 5 
 6 export {
 7     toast,
 8 } from './Toast';
 9 
10 export {
11     alertNative,
12     confirm,
13 } from './Modal';
14 
15 export {
16     actionSheet,
17 } from './Select';
18 

不足之處

這套架構模型的優勢是分工明確，將界面、業務、功能分開來，對於比較成熟的產品是比較好的。而且把如今流行的面向對象編程和麪向函數編程都包括進去了。

不過對於初創產品，或者比較簡單的產品來講，體現不出優點，反而帶來負擔。最直白的來講，就是太煩了。
原本要改一點東西，只要找一個js文件，就是那個page總裁頁面，就能夠了。如今弄得又要找business助理，還要修改function具體幹活的，作完了還要轉成View Model這種指定的格式... .... 鏈路這麼長，想一想都頭大，可能我只是修改一個後臺返回字段而已啊，要改這麼多地方... ...