MVP初级学习

一、概述

       对于Android业务逻辑较轻的开发，基本都是采用的MVC（Model-View-Controller）设计模式，但是对于业务逻辑较重并且为了方便版本升级维护，比较好的方式是采用MVP(Model-View-Presenter)开发。其实根本的思想就是解决对于模块（M、V、P、C都可以理解为模块）之间的耦合问题，我们都知道高耦合的模块是很难维护和升级的，一旦大尺度的升级往往所有工作要推倒重来，面向对象的设计的重要思想之一就是要尽可能的降低设计模块之间的耦合性。

下面先分别简单介绍一下MVP和MVC这两种设计模式。

二、MVC设计模式

M：Model(数据模型层)，对数据库的操作、对网络等的操作都应该在model里面处理，对业务计算等操作也是必须放在的该层的。

V：View(视图层)，一般就是指的界面UI。

C：Controller(控制层)，对于Android开发来讲一般就在activity中，处理整个业务逻辑。

三者的关系如下图所示（虚线表示发送事件，实线表示控制和获取）：

在实际的界面开发中，一个activity中要有视图V的配置和事件响应，事件响应中便涉及C的业务逻辑控制，业务逻辑控制下便会调用数据模型M，而V本身又可能需要直接使用数据模型。这样一个的设计模式之下，对于一个重量级的业务逻辑和比较复杂的数据模型，整个Activity的设计会变得非常庞大和复杂，因为不管是V、M还是C，都连接了很多其他模块的内容，而这些模块内容一旦发生改变，整段代码可能都不可用，并且需要到处修改，最后就是推倒重来，不容易进行代码维护和控件升级。

但是这个设计模型还是有一定的好处的，对于轻量级的业务逻辑，可以实现快速开发（相对于MVP）。

三、MVP

在实际开发中，一般是界面UI和业务逻辑根据市场等需求会不断更新和调整，因此V和C的改动是最多的。假如现在只是要修改UI，即V，由于M和C都用到了V，因此M和C都需要进行调整，对于庞大的业务逻辑来讲，这种调整的工作量本身就很大，还会引申出很多bug，因此代价是非常大的。因此大家开始想一种一劳永逸的办法，使得我再修改V的时候，只需要修改V就行，M和C都不需要改变，那该多好！其实这就是高度解耦的思想，于是就有了MVP。

说道高度解耦，相信有一个东西是大家非常喜欢的，就是接口，其实MVP就是利用了这个思想，统一了设计上的方式方法。

P：Presenter（表示层），有两层含义——1、MVC中的控制层全在这里实现了；2、对于V层，它还代表了M层，V层想要获得数据必须要经过V层，对于M层，它代表了V层，因此M层想要发送事件到V层要经过P。因此该层是V和M之间永恒的沟壑，不要指望V层直接操作M层。

MVP关系结构如下图

因此想要实现设计初衷里模块之间解耦，V和M必须要实现特定的接口供P调用。