Android架构模式：MVC & MVP & MVVM

Android架构模式：MVC & MVP& MVVM

 

前言

MVC、MVP、MVVM一直以来都是Android应用常见的架构模式，都是为了抽离出UI逻辑和业务逻辑。但是之前一直苦于不能理解其中的具体含义和差别，所以没办法将其运用在自己开发的应用中。所以我这次准备查阅各种资料全面理解这三种常用的架构，并尝试使用三种不同的架构模式实现一个简单的登录功能的Demo，希望通过清晰易懂的代码将三种模式之间的区别阐述清楚。如有不正确之处，欢迎批评指正相互探讨。

 

当前的问题

目前有很多的开发者选择的开发方式基本上可以认为是由两层构成，以Activity为首的一群Android组件负责处理与用户交互相关的逻辑，并单向调用业务逻辑层，逻辑层负责主要的业务逻辑如与服务器交互等。这样简单的架构虽然可以非常快速地构建，但是对于稍微复杂一点的应用来说，它的可维护性，可修改性，可测试性都会变得非常差。主要的原因如下，两层承担的职责界限不清晰，部分职责难以分配，导致有些应用的开发者将这些职责一股脑全部塞给了Activity，导致Activity过于臃肿，严重违反了“单一职责”原则和高内聚低耦合的要求，不符合面向对象程序设计思想，使组件的可维护性和可修改性严重下降。Activity既要负责响应用户请求处理部分业务逻辑，又要负责更改界面的展示，一旦程序出现问题，将非常难调试。

 

一、MVC

1.      基本概念

MVC模式是“Model-View-Controller”的缩写。MVC应用程序总是由这三个部分组成。 Event(事件)导致Controller改变Model或View，或者同时改变两者。只要Controller改变了Models的数据或者属性，所有依赖的View都会自动更新。

 

2.      MVC中三个组件之间的关系

a.      交互规则

Controller监听View的特定事件，当事件发生时，Controller将对View进行选择或改变Model。但是Controller不会去负责改变View的具体展示内容，它的职责是比较轻的。

View监听Model的特定事件，当Model发生改变而触发事件后，View将接到通知改变自身。另外，View可以直接向Model查询数据用于展示。

 

b.      引用的持有规则

Controller持有View的引用，以选择View进行展示。

Controller持有Model的引用，以修改数据模型。

View持有Model的引用，以直接查询数据。

注意：引用的持有意味着直接控制，而事件机制并不需要持有引用，采用事件机制可以将不同组件解耦。

 

3.      Android中MVC模式的实现

View：需要继承Android原生View的子类，包括TextView，EditText，ImageButton等组件以承担做为View的职责，包括查询Model等。通过为组件的不同事件添加监听者，实现事件机制，以事件通知的方式与Controller交互而不是直接调用Controller的方法。

Controller：由Activity和Fregment担当，当接收到View层的事件之后，直接调用Model的方法对其进行改变，同时选择对应的View。

Model：业务逻辑和数据代码。

 

二、MVP

 

1.      基本概念

MVP的全称为Model-View-Presenter，Model提供数据和对数据的操作逻辑，View负责显示，Controller/Presenter负责业务逻辑的处理。MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过 Controller。三者之间两两双向通信。

 

2.      对MVP的关键机制的解释

在MVP里，Presenter完全把Model和View进行了分离，主要业务逻辑在Presenter里实现。而且，Presenter与具体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变。不仅如此，我们还可以编写驱动模拟用户的各种操作，从而实现对Presenter的测试，而不需要使用自动化的测试工具。我们甚至可以在Model和View都没有完成时候，就可以通过编写Mock Object（即实现了Model和View的接口，但没有具体的内容的）来测试Presenter的逻辑。

 

3.      MVP中三个组件的关系

l  View负责展示，持有Presenter的引用，当有用户事件发生时，则通过直接调用Presenter的方法进行响应，其实是直接将任务委派给Presenter。同时，View要实现一个与Presenter交互的接口，让Presenter通过该接口改变View。

l  Presenter负责处理主要业务逻辑，通过接口与View进行交互而不是与具体的View交互。Presenter处理完任务后，调用上述接口改变View。

l  Model负责存储和处理数据，可以很好地设计为高内聚低耦合的组件，与Presenter直接交互。

        

4.      MVP模式在Android中的实现方法

View由Activity和各种View的子类实现，也就是使用Android提供的原生组件。与用户交互，初始化UI组件，将UI组件事件与Presenter相关联（如注册Listener）。Presenter由开发者自己设计实现相关的业务逻辑。  

Model由开发者自己设计实现数据的存储和与数据相关的逻辑。

 

这里我有一个问题：在有些资料中我看到Presenter与Model是双向连接也就是相互调用的，但是什么时候会出现Model调用Presenter的情况呢？我认为是不存在的。

 

 

三、MVVM

1.      基本概念

MVVM（Model-View-ViewModel）模式是根据MVP模式来的，可以简单的说，MVVM模式就是WPF（Windows-Presentation-Foundation）版的MVP模式。这种模式跟经典的MVP模式很相似，你需要一个为View量身定制model，这个model就是ViewModel，个人感觉有一点类似于ListView和Adapter的感觉。MVVM 在使用当中，通常会利用双向绑定技术，使得 Model 变化时，ViewModel 会自动更新，而 ViewModel 变化时，View 也会自动变化。所以，MVVM 模式有些时候又被称作：model-view-binder 模式。

 

2.      对MVVM关键机制的解释

View在展示中使用到的数据将和与之对应的ViewModel中对应的数据项相绑定，这样一来View就不必关心自己展示的是什么了。View与ViewModel通过绑定机制降低了耦合度，ViewModel无需显示调用更改View。而VIewModel中的数据项又与Model中对应的数据项相绑定，当Model中的数据更新后，也不需要显示地改变ViewModel，而是同样通过绑定机制来改变，进一步解耦。

 

3.      MVVM中三个组件的关系

l  View与MVP中的view相似，它只负责展示数据而不负责交互逻辑和业务逻辑，将这些逻辑委派给ViewModel，每一个View都对应一个ViewModel。

l  ViewModel与View一一对应，类似于View要展示的数据的同步缓存，其数据项与View中显示的数据项进行绑定，当ViewModel中的数据项更新时，它就会通过绑定机制更新View的数据项，从而避免了对View的直接调用。另外，ViewModel还要承担MVP中P的职责。

l  Model与MVC、MVP中的Model基本一致，用于保存数据和对数据进行操作，应该能够达到功能内聚。其中部分数据项与ViewModel中要展示的数据项相互绑定，当用户操作通过View、ViewModel修改了Model中的数据时，由于绑定的原因会同时修改ViewModel。

 

关于MVVM我有一个问题：看到有些材料中（在前文中也提到过），数据绑定通常使用双向绑定，我个人认为这是不合理的， Model应该是一个功能内聚且通信内聚的定义良好的独立模块，它的内部数据不应该轻易遭到外部修改，如果通过双向绑定机制修改了Model中的数据，也就是没有通过接口调用进行修改，那么这个操作就会打破Model模块的内聚性，可能会导致一些意想不到的问题，毕竟Model的设计应该是通过暴露的公共接口进行操作才能保证其逻辑和概念的一致性。