Hi，大家好，我是编程小6，很荣幸遇见你，我把这些年在开发过程中遇到的问题或想法写出来，今天说一说android中的mvc模式_android10 桌面模式[通俗易懂],希望能够帮助你!!!。

学习Android的同学一定要了解的三种开发模式，不然自己写的项目采用的什么模式都不清楚

MVC，MVP，MVVM都是为了解决UI页面与逻辑代码分离而出现的模式，MVP和MVVM都是MVC的基础上演化而来

MVC：

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写

M——模型层（Model）负责处理数据的加载或者存储

V——视图层（View）负责界面数据的展示，与用户进行交互

C——控制器层（Controller）负责逻辑业务的处理

在MVC模式中，View层可以直接访问Model层和Controller层，所以View层包含Model层信息和Controller层的业务逻辑处理

在MVC模式中，Model层不依赖View层，但是View层依赖Model层，导致更改View层比较困难

优点：

耦合性低，生命周期成本低，部署快，可维护性高，适用于快速开发的小型项目

缺点：

不适合大型，中等项目，View层Controller层连接过于紧密

View层对Model层的访问效率低

一般的高级UI页面工具和构造器不支持MVC模式

注意：

Activity和Fragment既有View的性质，又具有Controller的性质，导致Acyivity和Fragment很重

MVC中View层与Model层直接交互，所以Activity和Fragment与Model的耦合性很高

MVP：

MVC全名是Model View Controller，是模型(mV----odel)－视图(view)－控制器(controller)的缩写

M——数据层（Model）负责对数据的存取操作，例如对数据库的读写，网络的数据的请求等

V——视图层（View）负责对数据的展示，提供友好的界面与用户进行交互，Android通常将Activity或者Fragment作为View层

C——控制器层（Controller）连接View层与Model层的桥梁并对业务逻辑进行处理

MVP模式将MVC中的Controller换成Presenter，同时改变了通信方向。
View与Model隔离，Presenter负责完成View层与Model层的交互。

 MVP执行流程：

• View层收到用户的操作
• View层把用户的操作交给Presenter
• Presenter直接操作Model层进行业务逻辑处理
• Model层处理完毕后，通知Presenter
• Presenter收到通知后，去更新View层

在MVP模式中，Model与View无法直接进行交互，所以Presenter层会从Model层获得数据，适当处理后交给View层进行显示

在MVP模式中，Presenter层将View层和Model层进行隔离，使View和Model之间不存在耦合，同时将业务逻辑从View层剥离

优点：

模型与视图完全分离，修改View而不Model

可以更高效的使用Model，所有的交互都发生在——Presenter内部

将一个Presenter用于多个视图，而不需要改变Presenter的逻辑，View变化比Model变化频繁

逻辑结构清晰，View层代码不再臃肿

缺点：

MVP模式基于接口设计，会增加很多类，代码逻辑虽然清晰，但代码量庞大

MVP适用于中小型项目，大型项目慎用

MVC和MVP的主要区别：

•  MVP中View与Model并不直接交互，而是通过与Presenter交互来与Model间接交互
• MVP中Controller是基于行为的，并且可以被多个View共享，Controller可以负责决定显示哪个View
• MVP中Presenter与View的交互是通过接口来进行的，更有利于添加单元测试。
• MVC中View可以与Model直接交互，通常View与Presenter是一对一的，但复杂的View可能绑定多个Presenter来处理逻辑 

注意：

MVP中将这三层分别抽象到各自的接口当中，通过接口将层次之间进行隔离

Presenter对View和Model的相互依赖也是依赖于各自的接口，符合了接口隔离原则

Presenter层中包含了一个View接口，并且依赖于Model接口，从而将Model层与View层联系在一起

View层会持有一个Presenter成员变量并且只保留对Presenter接口的调用，具体业务逻辑全部交由Presenter接口实现类中处理。

MVVM：

MVVM 即 Model-View-ViewModel

M——Model（模型）实体模型，定义实体类，获取业务数据模型，如通过数据库或者网络来操作数据等

V——View（视图）布局文件(XML），主要进行控件的初始化设置

VM——ViewModel（控制器）：连接 View 与 Model 的中间桥梁，ViewModel 与 Model 直接交互，通过DataBinding将数据变化反应给View

注：ViewModel可以理解为View与Presenter的合成体

优点：

1. 结构清晰，职责划分清晰
2. 模块间充分解耦
3. 在 MVP 的基础上，MVVM 把 View 和 ViewModel 也进行了解耦

• 低耦合

        MVVM 模式中，数据处理逻辑是独立于 UI 层的

        ViewModel 只负责提供数据和处理数据，不会持有 View 层的引用

        View 层只负责对数据变化的监听，不会处理任何跟数据相关的逻辑

        View 层的 UI 发生变化时，也不需要像 MVP 模式那样修改对应接口和方法实现，一般情况下ViewModel 不需要做太多的改动

• 数据驱动

        UI 的展现是依赖于数据的，数据的变化会自然的引发 UI 的变化，而 UI 的改变也会使数据 Model 进行对应的更新

        ViewModel 只需要处理数据，而 View 层只需要监听并使用数据进行 UI 更新

• 异步线程更新Model

        Model 数据可以在异步线程中发生变化，此时调用者不需要做额外的处理

        数据绑定框架会将异步线程中数据的变化通知到 UI 线程中交给 View去更新

• 方便协作

        View 层和逻辑层几乎没有耦合，在团队协作的过程中，可以一个人负责 UI，一个人负责数据处理。并行开发，保证开发进度

• 易于单元测试

       ViewModel 层只负责处理数据，在进行单元测试时，测试不需要构造一个 fragment/Activity/TextView 等来进行数据层的测试

       View 层也一样，只需要输入指定格式的数据即可进行测试，而且两者相互独立，不会互相影响

• 数据复用

       ViewModel 层对数据的获取和处理逻辑，尤其是使用 Repository 模式时，获取数据的逻辑完全是可以复用的

       开发者可以在不同的模块，多次方便的获取同一份来源的数据

       同样的一份数据，在版本功能迭代时，逻辑层不需要改变，只需要改变 View 层即可

今天的分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。