標籤:尋找 使用者 視圖控制器 軟體 階段 ffffff 讀取 連結 完美
小夥伴們,看到這個標題,映入腦海的是不是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的優點之一是可視性,因為視圖模型與視圖無關,因此每個實體都可以單獨測試
這種模式不能用於簡單的線性螢幕應用程式,否則可能會導致代碼更複雜,新開發人員難以維護。
各位老鐵,你們覺得那種模式更好?
其實在我看來,這些模式都是非常經典和非常好用的,每種模式都各有優點,也各有局限性;
其實,換一種思路:
以現有的人力資源和時間資源,如何才能更快更好地完成需求,適當考慮下如何為後期擴充或重構做準備,可能這才是符合“國情”的一種選擇!
技術選型,決策關鍵不在於每種技術方案的優劣如何,而在於你團隊的水平、資源的多寡,要根據實際情況選擇最適合你們當前階段的架構方案
小夥伴們,你們覺得呢?歡迎在下方留言哦,動動手指,關注我們吧!
Android項目開發該如何選擇架構模式?