MVC MVP的理解 - xulijun6564/Myblog GitHub Wiki

一、MVC MVC的全称是Model-View-Controller，也就是模型-视图-控制器。 在Android中View层一般由XML布局文件充当。在Model层中我们会进行一些数据处理的工作，比如网络数据请求、数据库操作等。Controller层通常由Activity、Fragment充当，并在其中进行界面、数据相关的业务处理。 可见在Android中，作为Controller的Activity或Fragment主要起到的作用就是解耦，将View和Model进行分离，两者在Activity中完成具体的操作。 下图是MVC架构的结构模型：

MVC

从图中可以看出，MVC的耦合性还是相对较高的，View和Model之间可以互相访问，导致三者间构成回路，同时核心的业务逻辑都写在Controller中，导致Controller中的代码略显臃肿，这也是我们开发中使用MVC模式所面对的问题，Activity或Fragment中的业务逻辑代码代码少则几百行多则上千行。

二、MVP MVP是MVC架构的一个演化版，全称是Model-View-Presenter。 和MVC架构相比，MVP架构在Android中场景应该是这样的，Model层同样提供数据操作的功能，但View层的职责由Activity、Fragment、或某个View控件担任，最后Presenter层作为View层和Model层沟通的中介。

通常在View层中，有一个Presenter成员变量，同时我们的View（可以是Activity、Fragment）需要实现一个接口，这样可以将View层中需要的业务逻辑操作通过该接口转交给Presenter来实现，进而Presenter通过Model得到相应的数据，并通过View层实现的接口返回到View中。这样View层和Model层的耦合就解除了，同时也将业务逻辑从View中抽离出来，转移到Presenter中，避免了Activity或Fragment过度臃肿，充斥大量业务逻辑代码。 MVP的结构模型如下：

MVP

从图中可以看出，MVP架构中，解除了View和Model间的耦合，使它们不能相互访问，核心的业务逻辑都集中在Presenter中。 随着产品的升级，UI会添加新的设计，业务逻辑也会更改，在MVC架构中，我们需要在View层处理这些变化，可是面对成百上千的代码，也是挺烦的。使用MVP架构能很好的降低View的复杂性，将业务逻辑分离到Prestener，它们之间通过接口通信，处理变化时只需要根据情况来扩展接口并在Prestener处理新的业务逻辑即可。

举个通俗点的例子： MVC：小明喜欢隔壁班小红，小明写了一封情书需要通过隔壁班小王，才能交给小红。 但是注意，我只是说能很大程度上解决，并不能彻底解决，也就是说小明如果发现了隔壁小王有问题，他仍然可以选择直接把情书交给小红。

MVP：我给习大大寄了一个包裹，但这个包裹必须经过重重安检，才能交到习大大手上。我肯定不能直接把包裹给习大大。