我司產品屬於初創項目，早期業務相對簡單，最初項目中采用了簡單的MVC設計模式。然而隨著業務邏輯增多，某些Controller變得十分臃腫。

眾所周知，MVVM模式解決了Controller的臃腫並方便單元測試，為了方便後續代碼維護，在上版本新功能開發中，項目開始使用MVVM模式進行開發。 

但從上圖可以看出，MVVM模式中，Controller即便清爽了，但無疑是將臃腫的代碼移到了ViewModel中。

上述上個版本所開發的新功能為“愛瘋搶”，從業務交互及界面狀態展現來看，有多個界面存在相同的業務交互和元素展現，比如正在瘋搶列表、瘋搶商品詳情、我關注的瘋搶、我參與的瘋搶等等，這些界面都存在搶拍、提醒、取消提醒、關注、取消關注、購買、支付已搶拍成功商品等業務交互，同時按鈕展現（搶拍、提醒等狀態切換）及時間展現（搶拍開始時間、搶拍中倒計時、下次搶拍時間）等展示邏輯也無差別。

因此，結合這些具體情形，我在模塊類設計時，決定將這些公有的業務交互及界面展現狀態轉換邏輯抽離出來。依照MVVM設計模式，這些邏輯代碼理應放到ViewModel中。

但從實際出發，如果將所有的邏輯的都放進ViewModel，將導致ViewModel變得十分臃腫，同時使得具體業務邏輯代碼不夠粒度化，這樣無疑在代碼上耦合嚴重、不利於代碼擴展及重復利用。

舉個例子，假如某些界面出現不同的展現方式及邏輯，但卻具有相同的業務交互邏輯（搶拍、提醒、關注等），針對這種情況，就不能共用同一個ViewModel來滿足了，這時不得不新寫一個ViewModel來包含不同的展現邏輯和相同的業務交互邏輯，這無疑導致編寫重復的業務交互代碼，增加代碼維護成本。

為了ViewModel最終不變得臃腫，同時利於代碼擴展及重復利用，我想到將ViewModel的職責更進一步細化，ViewModel負責網絡請求及界面展示邏輯，而將業務交互部分單獨再抽出來，將其封裝在獨立的業務交互處理類Manager（或許這裡取名Manager不恰當，暫且先這樣）當中。

這樣，不同展現邏輯但具有相同業務交互邏輯的界面即可使用不同的ViewModel而共用同一個Manager了，滿足了一份業務交互邏輯代碼可以多處使用、多處組裝，在一定程度上不僅降低了開發工作量，同時增強了代碼的可維護性。

我將這種演化後的模式稱為MVVM+Manager模式，簡稱為MVVMM。Manager既然負責業務交互邏輯，這其中的業務就少不了和服務器交互、和本地數據交互等，因此，MVVMM模式的示意圖可以定義為如下所示： 

為了更具體說明MVVMM模式各個部分職責，我寫了一個簡明的邏輯描述Demo供參考。

對於復雜的功能模塊，ViewModel仍然顯得很臃腫的話，可繼續將其職責再細化，例如將網絡請求邏輯也從ViewModel中抽離出來單獨成為一個處理類，類似猿題庫中即使用單獨的DataController類來負責網絡數據請求，詳情可以參考博文。

上述有不足或疑問之處請留言交流。

MVVMM Demo：ttps://github.com/peterlogme/MVVMM.git

參考文章：

ReactiveCocoa and MVVM, an Introduction

ReactiveCocoa 和 MVVM 入門

猿題庫 iOS 客戶端架構設計