在項目開啟階段，其中一個很重要的環節就是選架構。
那么面對目前已知的這么多架構模式我們該怎么選擇呢？這確實是個很讓人頭疼的問題！
下面我就在這里梳理一下目前常見的一些架構模式。
先逐個對它們的分析，然后在從中找到它們的規律，之后就可以以不變應萬變，不會再被這些虛頭巴腦的名詞所迷惑。
本篇文章主要從兩個維度進行分析：
一、任務分配方式
二、邏輯分層方式
先看一下MVC、MVCS、MVVM、MVP、VIPER架構模式的任務分配方式
MVC
MVC是最經典的架構模式，它出現的時間非常早，也是最被人所熟知的。
MVC架構的任務分工為：
M-model：
1.數據結構表示
2.讀取本地數據
3.寫數據到本地
4.處理弱業務
C-Controller：
1.處理主要業務邏輯
2.處理交互事件
3.協調V-M數據流
V-View：
1.展示數據
2.處理非邏輯交互事件。
根據上面描述，總之一句話概括：
M：管理數據， C：處理數據， V：展示數據。
MVCS
看名字就感覺這個MVCS架構模式是從MVC中分化出來的，事實上也確實如此。
S為Store的簡稱，意思為“存儲，保存”。
下面來看一下多出一個S后，它們的分工有什么變化呢？
S-Store：
1.負責數據的存儲，數據本地持久化。
M-Model：
1.數據結構表示
2.讀取本地數據
3.處理弱業務
C-Controller：
1.處理主要業務邏輯
2.處理交互事件
3.協調V-M數據流
V-View：
1.展示數據
2.處理非邏輯交互事件。
從上面的分工可知C，V同MVC架構是完全一樣的，只有M的數據存儲任務被分離了出來。即：S分擔了M的數據管理任務，那么M和S其實都是數據管理的邏輯范疇了。
根據上面描述，總之一句話概括：
（M+S）：管理數據， C：處理數據， V：展示數據。
MVVM
MVVM為了解決前端的響應式編程而生，由於前端網頁混合了HTML、CSS和JavaScript，而且頁面眾多，代碼的組織和維護難度復雜，所以通過ViewModel實現View和Model的雙向綁定。
但是移動端不是前端，從業務處理邏輯上講，移動端要比前端處理的邏輯更多，你問我有啥依據。你可以把手機的網斷掉，進入帶有離線功能的APP，一套業務走下來，沒啥問題。但是用瀏覽器打開呢，縱然添加了緩存，也是不能將一套業務走完的。
所以說，移動端要比前端處理的邏輯多！
看到MVVM你會有疑問，為啥沒有C了，是不是用這個MVVM就不需要C了呢？如果你是移動端的同學，我給你講是有C的。
MVVM架構在移動端的完整叫法是：M-V-C-VM。
MVVM架構的任務分工為：
M-model：
1.數據結構表示
2.讀取本地數據
3.寫數據到本地
4.處理弱業務
C-Controller：
1.處理交互事件
2.協調V-M數據流
VM-ViewModel:
1.處理主要業務邏輯
V-View：
1.展示數據
2.處理非邏輯交互事件。
從上面的分工可知，VM分擔了C中的數據加工任務，將業務處理放到了ViewModel中，其他的M,V同MVC架構完全一樣。
總之一句話概括：
M：管理數據， （C+VM）：處理數據， V：展示數據。
MVP
MVP從MVC衍生而來，從名稱上看只是將C換成了P。其他都一樣。而事實上呢？
它們也確實這樣，P承擔了C的任務而已。
區別是：它們兩個的數據流向不一樣
MVC的數據流向圖
MVP的數據流向圖
對比一下，就可以一樣看出了。
MVC框架中，V的數據從Model中拿
MVP框架中，V的數據從Presenter中拿。
MVP架構的任務分工為：
M-model：
1.數據結構表示
2.讀取本地數據
3.寫數據到本地
4.處理弱業務
P-Presenter：
1.處理主要業務邏輯
2.處理交互事件
3.協調V，M數據流，從M讀取數據，將數據通過接口供V調用。
V-View：
1.展示數據
2.處理非邏輯交互事件。
根據上面描述，總之一句話概括：
M：管理數據， P：處理數據， V：展示數據。
VIPER
VIPER是責任粒度划分比較細的一個架構模式，是按照“責任單一原則”的標志來走的，每個類所承擔的任務更簡單。
VIPER架構的任務分工為：
E-Entity：
1.數據結構表示
2.讀取本地數據
3.寫數據到本地
I-Interactor：
1.處理主要業務邏輯
P-Presenter:
1.處理弱業務
2.處理交互事件
R-Routing:
1.處理視圖的展示順序邏輯或者說是控制器的跳轉控制
V-View：
1.展示數據
2.處理非邏輯交互事件。
根據上面描述，可粗略的概括為：
E：管理數據， （I+P+R）：處理數據， V：展示數據。
架構從邏輯分層上講，常見有兩種：
三層架構：展示層，業務層，數據層。
四層架構：展示層，業務層，網絡層，本地數據層。
架構從任務分配上講，常見有五種：
MVC、MVCS、MVVM、MVP、VIPER
而通常在工程中，這兩個維度的思想是同時存在的。
比如：三層MVC架構，四層MVC架構。
前面的層級表示邏輯分層方式
后面的形式表示任務分配方式
對於上面講的五種任務分配方式，因為是已經被人熟知，所有被大工程所采用。
但是目前有個疑惑
如果有時候一個業務模塊很負責時，會不斷的講業務分拆。會產生很多種目錄與文件。
如果模塊內視圖控制器跳轉邏輯負責時，會引入中介者模式進行統一管理跳轉。
這時，模塊內的任務分配文件相對於這五種架構模式，顯得有點四不像了。
這時就會疑惑，
我這到底用的是什么架構模式啊？
通過上面五種架構責任划分的介紹，我們可以知道
無論是什么架構模式，它們的區別是：任務的分配方式不同罷了。
雖然我們在任務分配后的文件和目錄四不像，但是可以滿足我們的業務需求和功能擴展，這就夠了。
不要被形式上所限制。
那么什么是好的架構模式呢？
個人認為比較好的架構模式為：三層MVC架構
任務分配方法是以MVC任務分配方案為基礎，按照一定的原則進行個性化分配。
采用如下分配原則：
1.保留當前角色的主要功能，拆分次要功能。
2.弱業務功能放到Model中，盡量不要放到Controller里去。
3.拆分出去的業務功能盡量封裝成可復用組件、對象或協議。
4.控制好拆分粒度，調用接口少參或無參。
這樣不管形式如何變化，只有架構邏輯分層在，同時滿足業務需要和功能擴展就是好架構。