MVC、MVCS、MVVM、MVP、VIPER等這麼多架構模式哪個好呢？

在項目開啓階段，其中一個很重要的環節就是選架構。

那麼面對目前已知的這麼多架構模式咱們該怎麼選擇呢？這確實是個很讓人頭疼的問題！

 

下面我就在這裏梳理一下目前常見的一些架構模式。

先逐個對它們的分析，而後在從中找到它們的規律，以後就能夠以不變應萬變，不會再被這些虛頭巴腦的名詞所迷惑。

 

本篇文章主要從兩個維度進行分析：

1、任務分配方式

2、邏輯分層方式

 

先看一下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.控制好拆分粒度，調用接口少參或無參。

 

這樣無論形式如何變化，只有架構邏輯分層在，同時知足業務須要和功能擴展就是好架構。