MVP?MVC?移動開發如何選擇正確的框架?

設計模式 程序員 Cocoa 通信 IT168企業級 2017-06-26

設計模式和架構對創建一個成功可靠的應用程序至關重要,可是具備哪些特徵才算得上一個好的架構呢?MVP、MVC和MVVM似乎都不錯,該如何選擇呢?

MVP?MVC?移動開發如何選擇正確的框架?

為什麼以及如何選擇正確的架構?

如果一開始不在乎架構、後期將會是修復錯誤和漏洞的噩夢。當然,程序員可以忽略像“Hello World”這樣簡單的應用程序中的體系結構,也可以忽略一些具有少量代碼結構的應用,因為可以直接在View Controller中編寫所有代碼。一旦代碼的量級上去了,畫風就徹底變了。我們可以在View Controller中找到一大堆代碼,它徹底成為了一個凌亂的視圖控制器或大型視圖控制器。即使我們遵循MVC指南編程,也可能發生這種情況。

良好架構的定義應該是這樣的:

1、實體間平衡分配

2、可讀性

3、可測性

4、易於使用和可維護性。

為什麼實體之間要平衡分配?

減少複雜性最簡單的方法是將不同實體之間的職責分開。它應該遵循單一責任原則,應該有一個唯一的理由來改變。

讓我們考慮一個關於在視圖中創建pdf並打印該報告的類的示例。現在想象一個可以執行這兩個更改的類。首先,它加載來自Web服務器或數據庫的數據,其次,它改變了用戶界面格式。這兩個任務完全不同,第一個是實質性的變化,而設置用戶界面完全是一個美化的過程。按照單一責任原則,這兩者是獨立的責任,實體之間也應該是獨立的。這樣分配可以保證程序的健壯性。

為什麼需要可測性?

可測性並不意味著測試。當一個有效的測試策略用於驗證某些實現與其規範的一致性時,應用程序就被認為是可測試的。編寫自動化測試非常簡單,因為當你完成一個組合根時,它就可以獨立測試了。這些測試可以讓開發人員在將應用程序交付給用戶設備之前查找和修復錯誤。

為什麼易於使用?

程序員都明白,編寫的代碼越少,錯誤的機會就越少;擁有的代碼越多,錯誤就越多。如果代碼邏輯混亂,維護成本就會相應地上升。好的代碼,即使一個新的開發人員接手,也可以輕鬆掌握。

現在我們有很多設計模式,我們可以根據我們的項目的要求選擇:

  • MVC

  • MVP

  • MVVM

MVC

Model-View-Controller是用於創建軟件應用程序的廣泛模式。目前市面上的大多數應用程序和框架都實現了這種設計模式。

MVP?MVC?移動開發如何選擇正確的框架?

Model層是域數據所在的位置,它管理讀取和寫入數據以及持久狀態。諸如持久性、網絡代碼、模型對象和操縱數據的解析器等保留在這裡。

View層是應用程序的面孔,是負責演示(用戶界面)並處理用戶交互的地方。

Controller層作為黏合劑,也就是Model層和View層之間的中介(模型和視圖)。它通過對用戶在View中執行的操作進行響應並更新Model層的數據來改變模型。

現在,MVC有什麼問題? 如果我們嘗試構建複雜的應用程序,就會變得困難重重。隨著時間的推移,越來越多的代碼被轉移到Controller,使它們更加脆弱和臃腫。Controller與View緊密耦合,如果我們嘗試在View中更改某些內容,我們必須回到Controller層並在那裡進行更改,這違反了權限特徵之間的均衡分配。

誰來拯救MVC架構呢?

MVP

MVP代表Model-View-Presenter; Cocoa對MVC承諾可在MVP身上實現。它實現了可測試的和清晰的View和Model層分離。

MVP?MVC?移動開發如何選擇正確的框架?

該Model層與MVC模型相同,它管理讀寫數據和持久狀態,這部分沒有變化。

View部分包括視圖和視圖控制器。此處的視圖將用戶交互委託給Presenter層,MVP中的視圖可能比較愚蠢,並且不包含可以查詢模型的邏輯。

Presenter層包含處理用戶交互的邏輯。它沒有任何UIKit依賴關係。Presenter的責任是與Model層進行通信,將數據轉換為用戶友好的格式,然後更新View層。

在MVP中,視圖控制器被視為View的子類,而不是Presenter。責任分配在Model和Presenter之間,因為View不包含任何邏輯,從而實現均衡的特徵分配。代碼現在更整潔,可以輕鬆地為Presenter進行單元測試。

我們不能說MVP是一個完美的模式,或者是不是應該遵循MVP,而不需要符合應用程序的要求。 MVP不適合簡單的應用,它將導致編寫樣板代碼從獲得視圖的接口開始工作。

MVVM

MVVM是最新的模型——視圖模式之一。它代表Model-View-ViewModel。ViewModel是觀察者設計模式的實現,其中model中的任何更改都將在View和ViewModel中表示出來。現在,當我們考慮使用MVVM時,我們會考慮使用Reactive Cocoa,儘管可以使用簡單的綁定來構建MVVM模式。MVVM包括:

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的優點之一是可視性,因為視圖模型與視圖無關,因此每個實體都可以單獨測試。這種模式不能用於簡單的線性屏幕應用程序,否則可能會導致代碼更復雜,新開發人員難以維護。

所以,你最喜歡的架構是什麼?

相關推薦

推薦中...