关于Android中MVVM,MVC和MVVM的那些事

一 . MVC:Model-View-Controller

MVC全名是：Model(模型) View(视图) Controller(控制器) 是软件[架构]中最常见的框架，简单来说，就是通过Controller的控制去操作Model层的数据，并且返回给View作展示。

1.MVC的工作原理？

1. View接受用户的交互请求。

2. View将请求转交给Controller。

3. Controller操作Model进行数据更新。

4. 数据更新之后，Model通知View数据变化。

5. View显示更新之后的数据。

2.MVC优点？

1）把业务逻辑全部分离到Controller中，模块化程度高。当业务逻辑变更的时候，不需要变更View和Model，只需要更换Controller就行了。 2）须手动或通过观察者模式进行多视图更新。

3.MVC缺点？

1）Controller测试困难。Controller不知道任何View的细节，一个Controller能被多个View使用。 2）View无法组件化，复用性较差。View是强依赖特定的Model的，如果需要把这个View抽出来作为一个另外一个应用程序可复用的组件就困难了，因为不同程序的的Model是不一样的。

4.使用场景？

适用于较小，功能较少，业务逻辑较少的项目。

二 . MVP:Model-View-Presenter

Presenter将Model的变化返回给View。和MVC不同的是，presenter会反作用于view，不像controller只会被动的接受view的指挥。正常情况下，发现可以抽象view，暴漏属性和事件，然后presenter引用view的抽象。这样可以很容易的构造view的mock对象，提高可单元测试性。在这里，presenter的责任变大了，不仅要操作数据，而且要更新view。 　　在Passive View中，为了减少UI组件的行为，使用controller不仅控制用户事件的响应，而且将结果更新到view上。可以集中测试controller，减小view出问题的风险。

1.MVP的工作原理？

image

1. View接受用户的交互请求

2. View将请求转交给Presenter

3. Presenter操作Model进行数据库更新

4. 数据更新之后，Model通知Presenter数据发生变化

5. Presenter更新View的数据

2.MVP优点？

1.便于测试。 　Presenter对View是通过接口进行，在对Presenter进行不依赖UI环境的单元测试的时候。可以通过Mock一个 View对象，这个对象只需要实现了View的接口即可，单元测试的时候就可以完整的测试Presenter业务逻 辑的正确性。 　2.View可以进行组件化。 　在MVP当中，View不依赖Model。这样就可以让View从特定的业务场景中脱离出来，可以说View可以做到对业务逻辑完全无知。它只需要提供一系列接口提供给上层操作。 　3.View高度复用。 　4.解耦。

3.MVP缺点？

1.维护比较困难。 　Presenter中除了业务逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，造成Presenter比较笨重，维护起来会比较困难。

4.使用场景？

视图界面不是很多的项目中。

三 . MVVM:Model-View-ViewModel

MVVM是在原有领域Model的基础上添加一个ViewModel，这个ViewModel除了正常的属性意外，还包括一些供View显示用的属性。例如在经典的MVP中，view有一个属性ischeck，需要在presenter中设置view的ischeck值。但是在MVVM中的presenter也会有一个ischeck属性来同步view的ischeck属性，可能会用到observer模式同步ischeck的值。在MVVM中，presenter被改名为ViewModel，就演变成了你看到的MVVM。在支持双向绑定的平台，MVVM更受欢迎。例如：微软的WPF和Silverlight。

1.MVVM优点？

1.提高可维护性。 　解决了MVP大量的手动View和Model同步的问题，提供双向绑定机制。提高了代码的可维护性。 　2.简化测试。 　因为同步逻辑是交由Binder做的，View跟着Model同时变更，所以只需要保证Model的正确性，View就正确。大大减少了对View同步更新的测试。 　3.ViewModle易于单元测试。

2.使用场景？

适用于界面展示的数据较多的项目。

四.MVC、MVP与MVVM的关系

1.MVC->MVP->MVVM演进过程

MVC -> MVP -> MVVM 这几个软件设计模式是一步步演化发展的，MVVM 是从 MVP 的进一步发展与规范，MVP 隔离了MVC中的 M 与 V 的直接联系后，靠 Presenter 来中转，所以使用 MVP 时 P 是直接调用 View 的接口来实现对视图的操作的，这个 View 接口的东西一般来说是 showData、showLoading等等。M 与 V已经隔离了，方便测试了，但代码还不够优雅简洁，所以 MVVM 就弥补了这些缺陷。在 MVVM 中就出现的 Data Binding 这个概念，意思就是 View 接口的 showData 这些实现方法可以不写了，通过 Binding 来实现。

2.三者相同之处

如果把这三者放在一起比较，先说一下三者的共同点，也就是Model和View：

Model：数据对象，同时，提供本应用外部对应用程序数据的操作的接口，也可能在数据变化时发出变更通知。Model不依赖于View的实现，只要外部程序调用Model的接口就能够实现对数据的增删改查。

View：UI层，提供对最终用户的交互操作功能，包括UI展现代码及一些相关的界面逻辑代码。

3.三者相异之处

三者的差异在于如何粘合View和Model，实现用户的交互操作以及变更通知

Controller Controller接收View的操作事件，根据事件不同，或者调用Model的接口进行数据操作，或者进行View的跳转，从而也意味着一个Controller可以对应多个View。Controller对View的实现不太关心，只会被动地接收，Model的数据变更不通过Controller直接通知View，通常View采用观察者模式监听Model的变化。

Presenter Presenter与Controller一样，接收View的命令，对Model进行操作；与Controller不同的是Presenter会反作用于View，Model的变更通知首先被Presenter获得，然后Presenter再去更新View。一个Presenter只对应于一个View。根据Presenter和View对逻辑代码分担的程度不同，这种模式又有两种情况：Passive View和Supervisor Controller。

ViewModel 注意这里的“Model”指的是View的Model，跟MVVM中的一个Model不是一回事。所谓View的Model就是包含View的一些数据属性和操作的这么一个东东，这种模式的关键技术就是数据绑定（data binding），View的变化会直接影响ViewModel，ViewModel的变化或者内容也会直接体现在View上。这种模式实际上是框架替应用开发者做了一些工作，开发者只需要较少的代码就能实现比较复杂的交互。

五.总结

MVP和MVVM完全隔离了Model和View，但是在有些情况下，数据从Model到ViewModel或者Presenter的拷贝开销很大，可能也会结合MVC的方式，Model直接通知View进行变更。在实际的应用中很有可能你已经在不知不觉中将几种模式融合在一起，但是为了代码的可扩展、可测试性，必须做到模块的解耦，不相关的代码不要放在一起。网上有一个故事讲，一个人在一家公司做一个新产品时，一名外包公司的新员工直接在View中做了数据库持久化操作，而且一个hibernate代码展开后发现竟然有几百行的SQL语句，搞得他们惊讶不已，一时成为笑谈。

个人理解，在广义地谈论MVC架构时，并非指本文中严格定义的MVC，而是指的MV*，也就是视图和模型的分离，只要一个框架提供了视图和模型分离的功能，我们就可以认为它是一个MVC框架。在开发深入之后，可以再体会用到的框架到底是MVC、MVP还是MVVM。