VIPER 和 MVVM 到底有什麼區別

先來快速地過一遍 mvvm 和 viper.

什麼是 mvvm？

什麼是 viper？

bohdan orlov: ios architecture patterns*

我們的主要目標是什麼？

首要的目標是將ui和業務邏輯分離。這樣才可以在不破壞任何業務邏輯的情況下去更新ui，或者單獨地去測試業務邏輯的**。事實上mvvm和viper都可以達到這個目標，只是方式不一樣而已。從這個角度來看的話，它倆的結構可以像下面這樣：

mvvm的 ui 層只有乙個 view 元件，而 viper 將 ui 層拆分成了三個元件：view, presenter 和 router. 而業務層顯然兩者基本差不多。接下來我們通過例子看看他倆在 ui 層的區別。

protocol
movielistview: movielistviewmodeldelegate
protocol
movielistviewmodeldelegate: class
protocol
movielistviewmodel
var movies: [movie] 
func
fetchmovies()}
複製**

資料流：

假設場景：實現 macos 版本

protocol
movielistview: movielistpresenterdelegate
protocol
movielistpresenterdelegate
protocol
movielistpresenter: movielistviewmodeldelegate
protocol
movielistviewmodeldelegate: class
protocol
movielistviewmodel
var movies: [movie] 
func
fetchmovies()}
複製**

資料流：

假設場景：ios 重設計

幾周後，蘋果發布了ios 26，jone ive 又雙叒叕宣布了乙個全新的設計系統。我們的設計師看了以後賊興奮並且也很快就搞了一套全新的設計稿出來。現在我們的工作變成了實現這套全新的ui，並確保可以用a/b testing來控制只讓一部分使用者顯示這套ui。我們這麼優秀的工程師，這點改動不算啥對吧。我們只需要寫乙個新的 ios view 並遵循movielistview協議，然後繫結 presenter 就行了，簡直不要太簡單。

protocol movielistview: movielistpresenterdelegate

複製**

在實現這個新類的時候，我們會意識到showdetailview在新舊view的實現是一樣的。我們可能會想到複製貼上這部分**，不過我們這麼優秀的工程師，怎麼可能允許複製貼上**對吧？ ok，我們把這部分邏輯也挪出來，並且把這個元件叫 router, 同樣，這個名字也是純屬偶然。

protocol movielistrouter

複製**

router 作為當前頁面的代言人，負責在需要的時候顯示對應的詳情頁。但是這個元件應該放在哪呢？放在新舊兩版view裡嗎？聽上去也可以不過就以往經驗來看，除非確實需求發生變化，還是不要頻繁改變 view 的**比較好。還是讓我們把這個責任交給 presenter 吧，讓它來持有 router. 這樣當使用者行為發生，presenter 接收到這個事件時，它可以決定是呼叫 view model 來做計算還是呼叫 router 來實現導航的功能。現在我們把導航的邏輯也復用了，可以發版啦。我們一起看看最終的**結構：

protocol
movielistview: movielistpresenterdelegate
protocol
movielistpresenterdelegate
protocol
movielistpresenter: movielistviewmodeldelegate
protocol
movielistrouter
protocol
movielistviewmodeldelegate: class
protocol
movielistviewmodel
var movies: [movie] 
func
fetchmovies()}
複製**

看到這裡，我想你應該 get 到了吧，這時候我們把movielistviewmodel改名為movielistinteractor的話, **就變成了 100%的viper，但同時又沒有違背 mvvm 的原則。

總結軟體架構說白了就是一堆的規則。有的架構規則多，有的規則少。使用一種架構並不意味著就是完全摒棄另外一種。尤其是當我們在討論mvc, mvvm 和 viper的時候。

從左到右，是乙個擴充套件性的演化，而不是前後矛盾。viper 是這三者當中的最細化的版本，這也是為什麼很多人認為它是設計過度了，而且事實上我也覺得這些人的的批評是對的。 viper一共有5個元件，然而你卻不一定在所有場景裡都需要全部的5個元件。我認為我們在開發過程中應該把精力放在需求本身而不是盲目地去遵循一些設計規則。對於 viper，我的建議是：

關於viper，我在之前一直有所耳聞，但是因為沒有在專案中實踐過，對於細節實際上是一知半解的。這篇文章從乙個非常好的角度分析了viper和mvvm的區別，我看完後收益頗豐。因此在這裡將其翻譯為中文，以便自己日後回顧。

對於架構模式，我自己的觀點，和文中的觀點非常類似，我認為專案中選擇怎樣的架構模式根本不重要，我們的目的只有乙個，那就是解耦且易擴充套件。

被業界diss無數次的mvc，實際上在優秀的程式設計師手裡，照樣能夠發揮得很好，但是到了一些相對初級的開發者那，則會有massive controller的問題，而這裡面最主要的原因，我認為就是mvc制定的規則太少了。

資深一些的開發者，他們對軟體架構的原則了解於心，因此不論架構模式的規則是多還是少，從他們手中產出的**始終能維持在乙個優雅的程度。因此，mvc在不同的人手中會有不同的結果。

而規則相對較多的mvvm，以及viper，在自身規則上做了更多的限制，使得不論什麼水平的開發者在遵循這些規則進行業務開發後，**質量能夠保持在乙個相對不錯的水平。

因此在我看來，選擇怎樣的架構模式取決於團隊的平均能力，大體上來說，團隊能力可以和架構模式的規則數量成反比。

對於業務的架構模式有什麼問題，歡迎一起討論。

VIPER 和 MVVM 到底有什麼區別

VIPER 和 MVVM 到底有什麼區別

Web Service和WCF的到底有什麼區別

Web Service和WCF的到底有什麼區別

VIPER 和 MVVM 到底有什麼區別

VIPER 和 MVVM 到底有什麼區別

Web Service和WCF的到底有什麼區別

Web Service和WCF的到底有什麼區別

相關推薦