小伙伴們，看到這個標題，映入腦海的是不是MVC、MVP、MVVM等這些熟悉的字眼？

創(chuàng)新互聯(lián)建站專注于中大型企業(yè)的網(wǎng)站設(shè)計制作、網(wǎng)站設(shè)計和網(wǎng)站改版、網(wǎng)站營銷服務，追求商業(yè)策劃與數(shù)據(jù)分析、創(chuàng)意藝術(shù)與技術(shù)開發(fā)的融合，累計客戶上千家，服務滿意度達97%。幫助廣大客戶順利對接上互聯(lián)網(wǎng)浪潮，準確優(yōu)選出符合自己需要的互聯(lián)網(wǎng)運用，我們將一直專注成都品牌網(wǎng)站建設(shè)和互聯(lián)網(wǎng)程序開發(fā)，在前進的路上，與客戶一起成長！

首先我們要知道為什么要選擇架構(gòu)模式？

1、代碼可讀性好

2、框架的核心思想：解耦

3、方便測試

4、易于使用和維護性好

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

為什么需要方便測試？

當一個有效的測試策略用于驗證某些實現(xiàn)與其規(guī)范的一致性時，應用程序就被認為是可測試的。這些測試可以讓開發(fā)人員在將應用程序交付給用戶設(shè)備之前查找和修復錯誤。

為什么易于使用？

程序員都明白，編寫的代碼越少，錯誤的機會就越少；如果代碼邏輯混亂，維護成本就會相應地上升，好的代碼，即使一個新的開發(fā)人員接手，也可以輕松掌握。

MVC

Model-View-Controller是用于創(chuàng)建軟件應用程序的廣泛模式。目前還有很多應用程序和框架都實現(xiàn)了這種設(shè)計模式；

Model層是域數(shù)據(jù)所在的位置，它管理讀取和寫入數(shù)據(jù)以及持久狀態(tài)。諸如持久性、網(wǎng)絡(luò)代碼、模型對象和操縱數(shù)據(jù)的解析器等保留在這里；

View層是應用程序的面孔，是負責演示（用戶界面）并處理用戶交互的地方；

Controller層作為黏合劑，也就是Model層和View層之間的中介（模型和視圖）。它通過對用戶在View中執(zhí)行的操作進行響應并更新Model層的數(shù)據(jù)來改變模型；

那么問題來了，如果我們使用MVC構(gòu)建復雜的應用程序，就會變得困難重重；

隨著時間的推移，越來越多的代碼被轉(zhuǎn)移到Controller，使它們更加脆弱和臃腫；

Controller與View緊密耦合，如果我們嘗試在View中更改某些內(nèi)容，我們必須回到Controller層并在那里進行更改，這違反了權(quán)限特征之間的均衡分配。

MVP

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

該Model層與MVC模型相同，它管理讀寫數(shù)據(jù)和持久狀態(tài)，這部分沒有變化。

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

Presenter層包含處理用戶交互的邏輯，它的責任是與Model層進行通信，將數(shù)據(jù)轉(zhuǎn)換為用戶友好的格式，然后更新View層。

在MVP中，視圖控制器被視為View的子類，而不是Presenter。責任分配在Model和Presenter之間，因為View不包含任何邏輯，從而實現(xiàn)均衡的特征分配。

我們不能說MVP是一個完美的模式，或者是不是應該遵循MVP，而不需要符合應用程序的要求；

MVP不適合簡單的應用，它將導致編寫樣板代碼從獲得視圖的接口開始工作。

MVVM

MVVM：視圖模式之一。它代表Model-View-ViewModel；

ViewModel是觀察者設(shè)計模式的實現(xiàn)，其中model中的任何更改都將在View和ViewModel中表示出來；

它包括：

Model：表示應用程序消耗的數(shù)據(jù)模型。此類聲明屬性以類似于上述兩種設(shè)計的方式來管理業(yè)務數(shù)據(jù)。

View：它類似于MVP。MVVM視圖包括視圖和視圖控制器。它只是保存數(shù)據(jù)并將所有內(nèi)容委托給Model的層。

ViewModel：ViewModel作為模型和視圖之間的鏈接。它負責包裝模型并準備視圖所需的可觀察數(shù)據(jù)。

我們通過記住一些要點來使用MVVM：

view層很笨，只知道如何呈現(xiàn)數(shù)據(jù)。

controller對model層一無所知。

model不了解viewmodel。

viewmodel擁有model。

view controller擁有view。

controller擁有view model，并通過ViewModel與model層進行交互。

MVVM幾乎滿足了所有功能，該架構(gòu)的責任分配在viewmodel和view之間；

使用MVVM的優(yōu)點之一是可視性，因為視圖模型與視圖無關(guān)，因此每個實體都可以單獨測試

這種模式不能用于簡單的線性屏幕應用程序，否則可能會導致代碼更復雜，新開發(fā)人員難以維護。

各位老鐵，你們覺得那種模式更好？

其實在我看來，這些模式都是非常經(jīng)典和非常好用的，每種模式都各有優(yōu)點，也各有局限性；

其實，換一種思路：

以現(xiàn)有的人力資源和時間資源，如何才能更快更好地完成需求，適當考慮下如何為后期擴展或重構(gòu)做準備，可能這才是符合“國情”的一種選擇！

技術(shù)選型，決策關(guān)鍵不在于每種技術(shù)方案的優(yōu)劣如何，而在于你團隊的水平、資源的多寡，要根據(jù)實際情況選擇最適合你們當前階段的架構(gòu)方案

小伙伴們，你們覺得呢？歡迎在下方留言哦，動動手指，關(guān)注我們吧！

網(wǎng)頁名稱：Android項目開發(fā)該如何選擇架構(gòu)模式？
文章來源：http://aaarwkj.com/article16/pjdjdg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、自適應網(wǎng)站、網(wǎng)站導航、App開發(fā)、商城網(wǎng)站、網(wǎng)頁設(shè)計公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)