在專案開啟階段，其中一個很重要的環節就是選架構。
那麼面對目前已知的這麼多架構模式我們該怎麼選擇呢？這確實是個很讓人頭疼的問題！
下面我就在這裡梳理一下目前常見的一些架構模式。
先逐個對它們的分析，然後在從中找到它們的規律，之後就可以以不變應萬變，不會再被這些虛頭巴腦的名詞所迷惑。
本篇文章主要從兩個維度進行分析：
一、任務分配方式
二、邏輯分層方式
先看一下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.控制好拆分粒度，呼叫介面少參或無參。
這樣不管形式如何變化，只有架構邏輯分層在，同時滿足業務需要和功能擴充套件就是好架構。