1、MVC框架
MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
简单来说就是通过controller的控制去操作model层的数据，并且返回给view层展示，当用户出发事件的时候，view层会发送指令到controller层，接着controller去通知model层更新数据，model层更新完数据以后直接显示在view层上，这就是MVC的工作原理。
如下图：
那具体到Android上是怎么样一个情况呢？
大家都知道一个Android工程有什么对吧，有java的class文件，有res文件夹，里面是各种资源，还有类似manifest文件等等。对于原生的Android项目来说，layout.xml里面的xml文件就对应于MVC的view层，里面都是一些view的布局代码，而各种java bean，还有一些类似repository类就对应于model层，至于controller层嘛，当然就是各种activity咯。大家可以试着套用我上面说的MVC的工作原理是理解。比如你的界面有一个按钮，按下这个按钮去网络上下载一个文件，这个按钮是view层的，是使用xml来写的，而那些和网络连接相关的代码写在其他类里，比如你可以写一个专门的networkHelper类，这个就是model层，那怎么连接这两层呢？是通过button.setOnClickListener()这个函数，这个函数就写在了activity中，对应于controller层。是不是很清晰。
1.1 MVC模式的角色说明
| 角色 | 描述 | Android中的对象 |
|---|---|---|
| Model(模型) | 负责提供数据模型以及处理，也负责在数据更改的时候提醒视图。（例如对数据库的操作，对网络数据的操作以及业务中的计算等操作应该放在该层） | Model类 |
| View(视图) | 数据的可视化，也就是让用户看到数据。 | xml文件，自定义View类，自定义Layout类 |
| Controller(控制器) | 负责处理用户交互。 | Activity，Fragment |
1.2 MVC的优缺点
- 优点
- 逻辑分离，专事专办，视图层和业务层分离，一定程度上降低了代码间的耦合性。
- 代码的重用性高（同样的方法，如果有其他的地方需要的话，可以直接调用）。
- 缺点
- 中小型项目用起来太麻烦（项目小的话，用该框架反而会变的复杂化，比如代码量，有时候一个函数就能搞定的，用该框架反而多此一举）。
- VC层耦合性过高，这个是特定针对Android的，因为在Android端，C层代表的是Activity/Fragment，这个是我们主要的用户交互界面，它总是会不可避免的染上一堆视图的逻辑（比如Activity/Fragment切换，显示Dialog，绑定控件）。这种情况下C层并没有完全的C，而加入了一部分V层的操作。
- 随着界面及其逻辑的复杂度不断提升，Activity类的职责不断增加，以致变得庞大臃肿。
- M层的逻辑太多，M层不仅要负责数据的生成，还要负责数据的加工，更要负责视图的提醒这种情况下M层的任务太重且类型太多，就不易于维护。
2、MVP框架
全称：Model-View-Presenter ；MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。
从图中就可以看出，最明显的差别就是view层和model层不再相互可知，完全的解耦，取而代之的presenter层充当了桥梁的作用，用于操作view层发出的事件传递到presenter层中，presenter层去操作model层，并且将数据返回给view层，整个过程中view层和model层完全没有联系。看到这里大家可能会问，虽然view层和model层解耦了，但是view层和presenter层不是耦合在一起了吗？其实不是的，对于view层和presenter层的通信，我们是可以通过接口实现的，具体的意思就是说我们的activity，fragment可以去实现实现定义好的接口，而在对应的presenter中通过接口调用方法。不仅如此，我们还可以编写测试用的View，模拟用户的各种操作，从而实现对Presenter的测试。这就解决了MVC模式中测试，维护难的问题。
1.1 MVP模式的角色说明
| 角色 | 描述 | Android中的对象 |
|---|---|---|
| Model(模型) | 主要做一些数据处理, 网路请求。Presenter 需要通过 Model 层存取、获取数据，Model是封装了数据库 Dao 层或者网络获取数据的角色，或者两种数据获取方式的集合。 | Model类（数据库，网络数据） |
| View(视图) | 用户界面，Activity、Fragment 或者某个 View 控件，含有一个 Presenter 成员变量，通常 View 层需要实现一个逻辑接口，将 View 上的操作通过会转交给 Presenter 进行实现，最后 Presenter 调用 View 逻辑接口将结果返回给 View 元素。 | Activity，Fragment |
| Presenter(协调者) | 交互中间人，核心逻辑，处理 View 的业务逻辑，沟通 View 和 Model 的桥梁，Presenter 持有的 View、Model 引用都是抽象，它从 Model 层检索数据后返回给 View 层，使得 View 和 Model 没有耦合，也将业务逻辑从 View 层抽取出来，经常会执行耗时操作。 | Presenter类/Controller类 |
1.2 MVP的优缺点
- 优点
- 复杂的逻辑处理放在presenter进行处理，减少了activity的臃肿。
- M层与V层完全分离，修改V层不会影响M层，降低了耦合性。
- 可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。
- P层与V层的交互是通过接口来进行的，便於单元测试。
- 缺点
- 由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁，视图需要改变，一般presenter也需要跟着改变。
3、MVVM框架
简介：MVVM是Model-View-ViewModel的简写。VM是ViewModel的缩写，VM可以理解为View的数据模型和Presenter的合体，ViewModel和View之间的交互通过data binding完成。它本质上就是MVP 的改进版。MVVM 就是将其中的View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开。当然这些事 ViewModel 已经帮我们做了，它可以取出 Model 的数据同时帮忙处理 View 中由于需要展示内容而涉及的业务逻辑。微软的WPF带来了新的技术体验，如Silverlight、音频、视频、3D、动画……，这导致了软件UI层更加细节化、可定制化。同时，在技术层面，WPF也带来了 诸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM（Model-View-ViewModel）框架的由来便是MVP（Model-View-Presenter）模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。它立足于原有MVP框架并且把WPF的新特性糅合进去，以应对客户日益复杂的需求变化。
1.1 MVVM模式的角色说明
| 角色 | 描述 | Android中的对象 |
|---|---|---|
| Model(模型) | 负责提供数据模型。 | Model类 |
| View(视图) | 数据的可视化，也就是让用户看到数据。 | 主要是Activity，Fragment |
| ViewModel | 负责处理用户交互和数据加工。 | ViewModel类 |
1.2 MVVM的优缺点
- 优点
低耦合。视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的"View"上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
Data Binding可以实现双向的交互，使得视图和控制层之间的耦合程度进一步降低，分离更为彻底，同时减轻了Activity的压力。
可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，使用Expression Blend可以很容易设计界面并生成xml代码。
可测试。界面素来是比较难于测试的，而现在测试可以针对ViewModel来写。
4、总结
MVP与MVC区别：
作为一种新的模式，MVP与MVC有着一个重大的区别：
- 在MVP中View并不直接使用Model，它们之间的通信是通过Presenter(MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过Controller。
- 在MVC里，View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。 在MVC模型里，更关注的Model的改变，而同时有多个对Model的不同显示，即View。所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。 虽然 MVC 中的 View 的确“可以”访问 Model，但是我们不建议在 View 中依赖Model，而是要求尽可能把所有业务逻辑都放在 Controller 中处理，而 View 只和 Controller 交互。
MVVM与MVP区别：
mvvm模式将Presener改名为View Model，基本上与MVP模式完全一致，唯一的区别是，它采用双向绑定(data-binding): View的 变动，自动反映在ViewModel，反之亦然。这样开发者就不用处理接收事件和View更新的工作，框架已经帮你做好了。