【Android】Mvp架构初探

MVP是单词Model View Presenter的首字母的缩写，分别表示数据层、视图层、发布层，它是MVC架构的一种演变。作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过 Controller。 首先我们先看下传统的MVC架构Model View Controller，我们把业务逻辑放到C层（ios的ViewController,android的Activity&Fragment），但是这里会引入另外一个问题，所有的逻辑都在C层，不可避免的会造成C层非常复杂，如果项目越来越大，C层的代码会更加臃肿，维护起来也非常麻烦，而且也没办法==简单的==做单元测试，试想做一个单元测试我们要加入多少逻辑代码？

综上所述我们总结下，现有的MVC模式存在以下问题：

1. 视图与控制器间的过于紧密的连接

视图与控制器是相互分离，但却是联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。

1. 视图对模型数据的低效率访问

依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。

1. 不太友好的单元测试

特别是App上做单元测试的时候很多东西依赖于系统框架，没法脱离用户接口来测试这些逻辑单元。使用MVP对Presenter的测试--不需要使用自动化的测试工具。 我们可以在Model和View都没有完成时候，就可以通过编写Mock Object（即实现了Model和View的接口，但没有具体的内容的）来测试Presenter的逻辑。

基于以上几点问题，就衍生了出了一些软件设计模式如MVP，MVVW。为什么是MVP？我们先看下面这张图

1. MVP分离了view和model层，Presenter层充当了桥梁的角色，View层只负责更新界面即可，这里的View我们要明白只是一个viewinterface，它是视图的接口，这样我们在做单元测试的时候可以非常方便编写Presenter层代码。关于mvp的代码测试，我们可以参考google给出的代码，google现在也在推行mvp，为此google发布了一些案例，大家可参考这里android-architecture

1. 厚重的Controller层代码也得到了释放，之前我们开发的时候会对UIViewController、Activity、Fragment编写很多的业务逻辑，尽管大家会将Service层做分离，如net层，DB层等，但还是无法避免类似的问题，activity uicontroller无法重复利用是非常难以忍受的。

2. 有一点还需要注意，presenter是双向绑定的关系，因此，在设计的时候就要注意接口和抽象的使用，尽可能的降低代码的耦合度，这也是mvp的宗旨。

so，转向mvp吧！我们先看下MVP几个单词的意思，以下是我个人的理解：

• View: 是显示数据（model）并且将用户指令（events）传送到presenter以便作用于那些数据的一个接口。View通常含有Presenter的引用。在Android开发中通常将Activity或者Fragment作为View层。

• Model: 对于Model层也是数据层。它区别于MVC架构中的Model，在这里不仅仅只是数据模型。在MVP架构中Model它负责对数据的存取操作，例如对数据库的读写，网络的数据的请求等。

• Presenter:对于Presenter层他是连接View层与Model层的桥梁并对业务逻辑进行处理。在MVP架构中Model与View无法直接进行交互。所以在Presenter层它会从Model层获得所需要的数据，进行一些适当的处理后交由View层进行显示。这样通过Presenter将View与Model进行隔离，使得View和Model之间不存在耦合，同时也将业务逻辑从View中抽离。

----未完待续----