MVC，MVP架构模式

MVC

MVC模式

为了将数据模式和视图分离开来，并以控制器作为连接两者的桥梁以实现解耦。

MVC是一种框架模式而非设计模式，GOF把MVC看作是3中设计模式：观察者模式、策略模式与组合模式的合体，而且其核心在观察者模式，也就是一个基于发布/订阅者模型的框架。

对于框架（框架模式）来说，通常是对代码的重用，而对设计（设计模式）来说通常是对设计的重用，可以简单地这样理解框架面向于一系列相同行为代码的重用，而设计则面向的是一系列相同结构代码的重用，我们平常所有的架构则介于框架与设计之间。

简而言之：框架是大智慧，用来对软件设计进行分工；设计模式是小技巧，对具体问题提出解决方案，以提高代码复用率，降低耦合度。
对这句话我的理解：MVC是个框架，把程序分为Model-View-Controller。单例模式是个设计模式，针对一个类只能有一个实例提出了静态内部类方式创建单例。

MVC在Android中的实现

View层：一般采用XML文件进行界面描述

Model层：

• 对应于本地的数据文件或网络获取的数据体
• 从各个数据源（网络/DB）获取保存等业务代码

Controller层：Activity承担

控制器Activity主要起到的作用就是解耦，将视图View和模型Model进行分离，两者在Activity进行绑定或完成其他逻辑。

自己开发遇到的认知错误：
经常把网络请求等操作都写在activity中，往往会导致activity中代码过多。
现在把这些网络请求代码写到Model中，这样有利于将业务的分离。

MVC在Android使用的实例：（网络请求是使用了Retrofit2）
https://github.com/yeoggc/MVCSimpleExample

MVP

MVP与MVC关系以及差异

MVP与MVC关系

在MVC中随着业务需求以及复杂酷炫UI不断增加，会有以下问题：

• 本属于View层中操作UI相关代码，被迫的转移到Activity，导致Activity即作为Controller也负责分担UI逻辑，以致变得庞大臃肿并且不方便进行单元测试。
• View层和Model层并未实现完全的解耦

而MVP的出现可以更好的解决上诉问题：

• 通过MVP我们可以把MVC进行如下优化，将Activity其中复杂的逻辑处理移至另外的一个类（Presneter）中时，Activity(Fragment)直接作为View层，它负责UI相关操作，建立UI元素与Presenter的关联，同时自己也会处理一些简单的逻辑(复杂的逻辑交由Presenter处理)。

• 通过MVP可以实现视图(View)与模型(Model)的完全解耦，让View专注于处理数据的可视化以及与用户的交互，同时让Model只关系数据的处理。

这里我们可以知道MVP和MVC有这样的关系：
MVP解决了MVC在业务需求以及复杂酷炫UI不断增加的背景下产生一些问题，MVP基于MVC，是MVC的增强版。

MVP与MVC主要差异

• MVP实现了View与Model的完全解耦，MVC中View可以与Model直接交互。
• MVP中P与View的交互通过接口进行的，有利于降低耦合，方便进行单元测试；MVC中C与View直接交互，高耦合，不方便进行单元测试。

MVP几个角色以及对应的职责

在MVP模式里通常有以下这几个角色：

1. View：负责绘制UI元素、与用户进行交互。通常是指Activity、Fragment或某个View空间;
2. View interface：需要View实现的接口，Presenter通过View interface与View进行交互，降低耦合，方便进行单元测试;
3. Model:主要是提供数据的存取功能以及操纵功能；可以简单的理解为Model层封装了数据库DAO以及网络获取数据的角色。
4. Model interface：与View interface作用类似，根据需求的复杂程度，决定是需要增加Model interfac。
5. Presenter：主要作为沟通View和Model的桥梁，它从Model层检索数据后，返回给View层，使得View层和Model层之间没有耦合，也将业务逻辑从View角色上抽离出来。

MVP模式图例

Presenter与Activity、Fragment的生命周期

在Activity被销毁之前，Presenter持有了Activity强引用并在执行一些耗时操作，导致Presenter一直持有Activity对象，使得Activity对象无法被回收，此时就发生了内存泄露。

如何解决这个样的问题？
Presenter由持有Activity强引用改成弱引用，并在Activity生命周期方法onDestroy中解除关联。
为什么是弱引用？因为Activity生命周期方法onDestroy不一定会被执行到，一旦发生这情况，弱引用也能够保证不会发生内存泄露。

小结

理想化的MVP模式可以实现一份逻辑代码搭配不同的显示界面，因为他们之间并不依赖于具体，而是依赖于抽象。这使得Presenter可以运用于任何实现了View逻辑接口的UI，使之具有更广泛的适用性，保证了灵活度。

MVP并不是一个标准化的模式，它有很多种实现方式，我们可以根据自己的需求和 自己认为对的方式去修正MVP方式，它可以随着Presenter的复杂度变化。只要保证我们是通过Presenter将View和Model解耦合、降低类型复杂度，各个模块可以独立测试、独立变化，这就是正确的方向。

从整体效果来说，MVP是开发过程中非常值得推荐的架构模式，它能够将各组件进行解耦，并带来良好的扩展性、可测试性，稳定性，可维护性，同事使得每个类型的职责相对单一、简单，避免了大量的"胖"的程序存在，例如数千行的Activity类。它有效的将业务逻辑、数据处理等工作从Activity等View元素中抽离出来，使得每个类尽可能简单，同时每个模块能够独立进行演化，它的思想也非常好地体现了面向对象的设计原则：抽象、单一职责、最小化、低耦合。

---

MVX

GUI应用程序：拥有图像界面的程序

先搞清楚一个顺序，是GUI应用程序的出现导致了MVC的产生。

有了View和Model的分层，那么问题就来了：View如何同步Model的变更，View和Model之间如何粘合在一起。（所谓的MVX中的X都可以归纳为对这个问题不同的处理方式）

M（Model）

Model层表示数据模型和业务逻辑，它代表着一类组件(components)或类(class)，这些组件或类可以向外部提供数据，同时也能从外部获取数据并将这些数据存储在某个地方。

model层主要负责：

• (检索数据)从网络，数据库，文件，传感器，第三方等数据源读写数据。

• (操纵数据)对外部的数据类型进行解析转换为APP内部数据交由上层处理。

• (存储数据)对数据的临时存储,管理，协调上层数据请求。

V（View）

在Android中View层一般是Activity、Fragment、View（控件）、ViewGroup（布局等）等。Android中视图包含着用户界面和界面逻辑。

view 层主要负责：

• 提供UI交互

X（C-Controller、P-Presenter、VM-ViewModel）

Controller控制器

Presenter

ViewModel视图模型

summary

MVC模式、MVP模式和MVVM模式都作为用来分离UI层与业务层的一种开发模式。这些模式之间的差异可以归纳为对这个问题处理的方式的不同。

参考：
http://www.jianshu.com/p/9a6845b26856
http://blog.csdn.net/vector_yi/article/details/24719873?utm_source=tuicool&utm_medium=referral