小夥伴們，看到這個標題，映入腦海的是不是MVC、MVP、MVVM等這些熟悉的字眼？
首先我們要知道爲什麼要選擇架構模式？
1、代碼可讀性好
2、框架的核心思想：解耦
3、方便測試
4、易於使用和維護性好
減少複雜性最簡單的方法是將不同實體之間的職責分開。它應該遵循單一責任原則，應該有一個唯一的理由來改變；
爲什麼需要方便測試？
當一個有效的測試策略用於驗證某些實現與其規範的一致性時，應用程序就被認爲是可測試的。這些測試可以讓開發人員在將應用程序交付給用戶設備之前查找和修復錯誤。
爲什麼易於使用？
程序員都明白，編寫的代碼越少，錯誤的機會就越少；如果代碼邏輯混亂，維護成本就會相應地上升，好的代碼，即使一個新的開發人員接手，也可以輕鬆掌握。
MVC
Model-View-Controller是用於創建軟件應用程序的廣泛模式。目前還有很多應用程序和框架都實現了這種設計模式；
Model層是域數據所在的位置，它管理讀取和寫入數據以及持久狀態。諸如持久性、網絡代碼、模型對象和操縱數據的解析器等保留在這裏；
View層是應用程序的面孔，是負責演示（用戶界面）並處理用戶交互的地方；
Controller層作爲黏合劑，也就是Model層和View層之間的中介（模型和視圖）。它通過對用戶在View中執行的操作進行響應並更新Model層的數據來改變模型；
那麼問題來了，如果我們使用MVC構建複雜的應用程序，就會變得困難重重；
隨着時間的推移，越來越多的代碼被轉移到Controller，使它們更加脆弱和臃腫；
Controller與View緊密耦合，如果我們嘗試在View中更改某些內容，我們必須回到Controller層並在那裏進行更改，這違反了權限特徵之間的均衡分配。
MVP
MVP代表Model-View-Presenter; Cocoa對MVC承諾可在MVP身上實現。它實現了可測試的和清晰的View和Model層分離。
該Model層與MVC模型相同，它管理讀寫數據和持久狀態，這部分沒有變化。
View部分包括視圖和視圖控制器，此處的視圖將用戶交互委託給Presenter層，MVP中的視圖可能比較愚蠢，並且不包含可以查詢模型的邏輯。
Presenter層包含處理用戶交互的邏輯，它的責任是與Model層進行通信，將數據轉換爲用戶友好的格式，然後更新View層。
在MVP中，視圖控制器被視爲View的子類，而不是Presenter。責任分配在Model和Presenter之間，因爲View不包含任何邏輯，從而實現均衡的特徵分配。
我們不能說MVP是一個完美的模式，或者是不是應該遵循MVP，而不需要符合應用程序的要求；
MVP不適合簡單的應用，它將導致編寫樣板代碼從獲得視圖的接口開始工作。
MVVM
MVVM：視圖模式之一。它代表Model-View-ViewModel；
ViewModel是觀察者設計模式的實現，其中model中的任何更改都將在View和ViewModel中表示出來；
它包括：
Model：表示應用程序消耗的數據模型。此類聲明屬性以類似於上述兩種設計的方式來管理業務數據。
View：它類似於MVP。MVVM視圖包括視圖和視圖控制器。它只是保存數據並將所有內容委託給Model的層。
ViewModel：ViewModel作爲模型和視圖之間的鏈接。它負責包裝模型並準備視圖所需的可觀察數據。
我們通過記住一些要點來使用MVVM：
view層很笨，只知道如何呈現數據。
controller對model層一無所知。
model不瞭解viewmodel。
viewmodel擁有model。
view controller擁有view。
controller擁有view model，並通過ViewModel與model層進行交互。
MVVM幾乎滿足了所有功能，該架構的責任分配在viewmodel和view之間；
使用MVVM的優點之一是可視性，因爲視圖模型與視圖無關，因此每個實體都可以單獨測試
這種模式不能用於簡單的線性屏幕應用程序，否則可能會導致代碼更復雜，新開發人員難以維護。
各位老鐵，你們覺得那種模式更好？
其實在我看來，這些模式都是非常經典和非常好用的，每種模式都各有優點，也各有侷限性；
其實，換一種思路：
以現有的人力資源和時間資源，如何才能更快更好地完成需求，適當考慮下如何爲後期擴展或重構做準備，可能這纔是符合“國情”的一種選擇！
技術選型，決策關鍵不在於每種技術方案的優劣如何，而在於你團隊的水平、資源的多寡，要根據實際情況選擇最適合你們當前階段的架構方案
小夥伴們，你們覺得呢？歡迎在下方留言哦，動動手指，關注我們吧！
