androidmvp結構

❶ android mvp mvvm怎麼選擇 簡書

1.MVC
傳統的Android App其實都是基於MVC的，Activity，Fragment相當於C,布局相當於V,數據邏輯相當於M
隨著業務的增長Controller里的代碼會越來越臃腫，因為它不只要負責業務邏輯，還要控制View的展示。也就是說Activity、Fragment雜糅了Controller和View，耦合變大。並不能算作真正意義上的MVC。
這也是為什麼後面的MVP會引起很多開發者興趣的原因了。
2.MVP
MVP架構其實可以說與MVC的架構還是有很大的差別的，數據邏輯相當於M，Activity（負責View的繪制以及與用戶交互）相當於V ，View於Model間的交互則為P
理論上感覺區別有點抽象，可以通過下面的圖來看一看其中的區別

❷ Android MVP 開發模式有哪些優缺點

MVP概念：

MVP(Model-View-Presenter) 是總所周知MVC模式的一個演變，主要目的都是劃分模塊職責，降低模塊耦合，易測試,提高代碼復用。

層級責任

• Model:負責數據的檢索,持久化等操作。

• View: 負責UI的繪制和用戶的交互。

• Presenter: 作為Model和View的中間協調部分,負責兩者之間的業務邏輯處理。

MVC模式的區別

• MVC模式允許View層和Model層直接通訊。

• 當某個View的功能很復雜的時候,View和Model的耦合度可能會很高。

• MVP模式就沒有這個問題,View會抽象出來一系列操作UI的介面。

• Presenter拿到的都是其他兩個層級的介面來做業務邏輯的處理，這樣不僅可以使View和Model之間的耦合度降低,還可以更易得進行單元測試。

MVP的優缺點

• 優點:降低耦合，層級職責更明顯，易於單元測試。

• 缺點:造成類數量爆炸，代碼復雜度和學習成本高，在某些場景下presenter的復用會產生介面冗餘。

❸ Android MVP架構中的Presentation層應該怎麼設計

對於MVP（Model View Presenter），大多數人都能說出一二：「MVC的演化版本」，「讓Model和View完全解耦」等等。本篇博文僅是為了做下記錄，提出一些自己的看法，和幫助大家如何針對一個Activity頁面去編寫針對MVP風格的代碼。
對於MVP，我的內心有一個問題：
為何這個模式出來後，就能被廣大的Android的程序員接受呢？
問了些程序員，他們對於MVP的普遍的認識是：「代碼很清晰，不過增加了很多類」。我在第一次看到MVP的時候，看了一個demo，看完以後覺得非常nice（但是回過頭來，自己想個例子寫，就頭疼寫不出來，當然這在後文會說）。nice的原因還是因為，這個模式的確讓代碼的清晰度有了很大的提升。
那麼，提升一般都是對比出來的，回顧下，沒有應用MVP的代碼結構。很多人說明顯是MVC么：
View：對應於布局文件
Model：業務邏輯和實體模型
Controllor：對應於Activity
看起來的確像那麼回事，但是細細的想想這個View對應於布局文件，其實能做的事情特別少，實際上關於該布局文件中的數據綁定的操作，事件處理的代碼都在Activity中，造成了Activity既像View又像Controller（當然了Data-Binder的出現，可能會讓View更像View吧）。這可能也就是為何，在該文中有一句這樣的話：
Most of the modern Android applications just use View-Model architecture，everything is connected with Activity.
而當將架構改為MVP以後，Presenter的出現，將Actvity視為View層，Presenter負責完成View層與Model層的交互。現在是這樣的：
View 對應於Activity，負責View的繪制以及與用戶交互
Model 依然是業務邏輯和實體模型
Presenter 負責完成View於Model間的交互
ok，先簡單了解下，文中會有例子到時候可以直觀的感受下。

❹ Android 中 MVC、MVP 和 MVVM 對比

MVC、MVP和MVVM是常見的三種架構設計模式，當前MVP和MVVM的使用相對比較廣泛，當然MVC也並沒有過時之說。

MVC (Model-View-Controller, 模型-視圖-控制器)，標準的MVC是這個樣子的：

簡述：

缺點：

MVP (Model-View-Presenter) 是MVC的演化版本，幾個主要部分如下：

簡述：

解釋：

優點：

缺點：

MVVM 是 Model-View-ViewModel 的簡寫。和 MVP 模式相比，MVVM 模式用 ViewModel 替換了 Presenter ，其他層基本上與 MVP 模式一致，ViewModel 可以理解成 是 View 的數據模型和 Presenter 的合體。MVVM 就是將其中的 View 的狀態和行為抽象化，讓我們將視圖 UI 和業務邏輯分開。

簡述：

缺點:

參考：

❺ android mvp是什麼意思

MVP模式是MVC模式在Android上的一種變體，要介紹MVP就得先介紹MVC。在MVC模式中，Activity應該是屬於View這一層。而實質上，它既承擔了View，同時也包含一些Controller的東西在裡面。這對於開發與維護來說不太友好，耦合度大高了。把Activity的View和Controller抽離出來就變成了View和Presenter，這就是MVP模式。
在Android項目中，Activity和Fragment占據了大部分的開發工作。如果有一種設計模式（或者說代碼結構）專門是為優化Activity和Fragment的代碼而產生的，你說這種模式重要不？這就是MVP設計模式。
按照MVC的分層，Activity和Fragment（後面只說Activity）應該屬於View層，用於展示UI界面，以及接收用戶的輸入，此外還要承擔一些生命周期的工作。Activity是在Android開發中充當非常重要的角色，特別是TA的生命周期的功能，所以開發的時候我們經常把一些業務邏輯直接寫在Activity裡面，這非常直觀方便，代價就是Activity會越來越臃腫，超過1000行代碼是常有的事，而且如果是一些可以通用的業務邏輯（比如用戶登錄），寫在具體的Activity里就意味著這個邏輯不能復用了。如果有進行代碼重構經驗的人，看到1000+行的類肯定會有所顧慮。因此，Activity不僅承擔了View的角色，還承擔了一部分的Controller角色，這樣一來V和C就耦合在一起了，雖然這樣寫方便，但是如果業務調整的話，要維護起來就難了，而且在一個臃腫的Activity類查找業務邏輯的代碼也會非常蛋疼，所以看起來有必要在Activity中，把View和Controller抽離開來，而這就是MVP模式的工作了。