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模式的工作了。