中小型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作一些簡單的拆分（抽象）。

總體架構

整體是基於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哈哈~）

總體代碼框架

框架又基於業務去設計和區分，爲了能夠更好的分工合做，更好的遷移代碼。 第一個Util裏放公共的代碼，和業務無關的工具類。好比說各類第三方的封裝，分類。 第二個'Dao'裏放的是和總體業務相關的工具類，好比說公共數據庫，公共網絡接口API。 第三個就是App涉及到的業務。 Lib是沒有pod庫導入的第三方庫。 Res就是資源庫，放圖片，Assets。 外面就是Base類，Base類裏不要放業務相關的代碼，就放基礎配置和基本API。

業務代碼層框架

當具體到某個業務裏的框架設計呢，咱們會將網絡層也作業務區分，而且散落到各個業務模塊中。能夠看到最上面是數據來源（不管後臺返回仍是數據庫都是數據的來源）。中間的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層的文檔就可使用了。

因此說業務層的框架設計能夠以下圖所示：

總結

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