中小型App的架構

Peter_shenlipingUpUp發表於2017-12-27
APP架構

引言

個人對於架構比較感興趣，平時有事沒事的都會逛逛部落格，看看書。然後組長要我分享下關於架構的知識。先來寫一份部落格捋捋思緒吧。 MVC模式，個人覺得是架構模式裡最強大的模式！能給予很多的架構啟發（包括後面出現的MVP,MVVM）。對於中小型App，簡單的MVC或者MVPC模式會更合適點。本文是基於MVC的思想去寫的。

Model還有胖瘦？

早在幾年前吧，國外對於胖瘦model這個概念，爭執了很久，最後的結果還是不了了之。。。因為無論是胖model還是瘦model，都各自具有各自的優缺點。那麼什麼是胖瘦model呢？ 所謂的胖model就是說，你的Model層上包含了部分弱業務，瘦Model就是單純的Model，只有屬性的對映。 舉個?： 比如說你的UserModel裡有性別這個熟悉，但是後臺返回或者資料庫儲存的欄位是0和1，你需要根據這個欄位去判斷男和女。如果是胖Model選手呢，很簡單啊，我在我的Model層裡就做好這些簡單業務的判斷，到時候ViewController需要用到的時候直接用就好了。但是胖Model比較難移植，而且修改或許會造成某些不必要的麻煩。而瘦model選手就不同，我的Model可以非常方便的直接ORM對映，我在我的ViewController裡需要用的時候去判斷下。不過這樣的結果就是違法了DRY原則(don't repeat yourself)。因為很多冗餘的程式碼沒有抽象出來，這樣的VC層看起來很臃腫。

至於我的態度，我更傾向於胖Model。傳統的MVC模式，會讓VC層非常的臃腫，早之前就很多人提出要給VC層瘦身。於是乎就把部分弱業務寫在model裡了，胖Model因此誕生了。至於後來的MVP，MVVM什麼的就更加抽象了。

什麼是架構

什麼是架構，可能很多人上來就是MVVM，MVC，然後羅列出一系列的優缺點巴拉巴拉。。。我個人覺得架構就是架構師根據當前業務複雜度和業務工程師去設計框架，目的就是讓業務工程師在寫業務的時候統一，方便，明白。而且可以比較簡單的上手，遷移，包括之後的演化也需要考慮到。 對於中小型的App來說，業務工程師不會很多，業務也不會很複雜。所以可以基於MVC做一些簡單的拆分（抽象）。

整體架構

基礎架構.png

總體是基於MVC，多加了一層Reformer。作用是將胖Model中的若業務部分抽出來，ViewController中的部分業務抽出來，放在Reformer中。所以我們的網路層的介面可以這樣設計

+ (void)requestBubleList:(BaseReFormer *)reformer
                     xxx:(NSString *)xxx
                callBack:(void (^)(int code))callback;
複製程式碼

業務程式猿只需要關注自己需要做什麼資料處理，業務邏輯，在Reformer中寫好。然後傳入這個Reformer和請求需要的引數就可以了，至於網路層做了什麼，其實並不需要了解。 Reformer用於處理業務和資料，Model用於資料管理，View用於資料展示，ViewController用於協調Model和View，並且響應互動（可能會涉及到部分業務）。

總體來說，弱化了原先在MVC中C層的作用，並且在設計過程中，少用繼承，多用組合，將能夠複用的程式碼用管理類管理起來。我把這個叫做MRVC框架（O(∩_∩)O哈哈~）

整體程式碼框架

image.png

框架又基於業務去設計和區分，為了可以更好的分工合作，更好的遷移程式碼。 第一個Util裡放公共的程式碼，和業務無關的工具類。比如說各種第三方的封裝，分類。 第二個'Dao'裡放的是和整體業務相關的工具類，比如說公共資料庫，公共網路介面API。 第三個就是App涉及到的業務。 Lib是沒有pod庫匯入的第三方庫。 Res就是資源庫，放圖片，Assets。 外面就是Base類，Base類裡不要放業務相關的程式碼，就放基礎配置和基本API。

業務程式碼層框架

image.png

當具體到某個業務裡的框架設計呢，我們會將網路層也做業務區分，並且散落到各個業務模組中。可以看到最上面是資料來源（無論後臺返回還是資料庫都是資料的來源）。中間的Mediator層是用於業務跳轉的，我們大部分時候寫頁面跳轉都是這樣寫的：

XXXViewController *controller = [XXXViewController new];
[self.navigationController pushViewController:controller animated:YES];
複製程式碼

這樣的壞處是A程式猿需要跳轉到B程式猿負責的已經完成的某一個業務頁面，但是A不熟悉B的程式碼，就要去問B，如果B不在的話，就要找，可能會很久，如果需要帶引數就更加尷尬了。所以我們可以新增個B業務的Mediator層的，用於跳轉。跳轉的介面都設計好，舉個?：

UserMediator.h

/**
 跳轉到個人詳情頁面

 @param from 跳轉的頁面
 @param user_id 使用者ID
 @param nickName 使用者暱稱
 */
+ (void)pushUserInfoContoller:(UIViewController *)from
                       userID:(long)user_id
                     nickName:(NSString *)nickName;
複製程式碼

當我們需要用到的時候，就呼叫[UserMediator pushUserInfoContoller:self userID:10086 nickName:@"中國移動"]。對於A來說去看看Mediator層的文件就可以使用了。

image.png

所以說業務層的框架設計可以如下圖所示：

中小型App的架構

總結

這個架構的好處 1.整體是分業務模組設計的，業務與業務之間沒有直接的耦合，因為中間多了層Mediator層。所以說業務的複用和遷移相對來說比較簡單，對於今後如果想要模組化也可以進一步迭代。如果還需要解耦合，就用runtime和dictionary傳參的方式，但是這樣的成本相對較高，對於API直觀程度不夠。 2.整體是MRVC設計，所以是輕量級的V層和對映級的Model層，中間業務都基本處於Reformer層。如果需要響應式程式設計的話，可以在Reformer層進行設計修改。 3.少用繼承，多用組合。對於程式碼遷移有很大的方便性，拔出蘿蔔帶出泥的這種現象會很少。 4.網路層介面的分模組可以和後臺架構保持一致，對於整體架構都比較好。

相關文章