谈谈对MVC、MVP和MVVM的理解

刚出来工作的时候维护过一个老系统，该系统是用微软的ASP（Active Server Pages 动态服务器页面）写的。每一个页面都是一个ASP文件，每一个一个ASP文件中又同时包含了HTML、CSS、Java Script、VB Script代码，把这么多代码糅合在一起，可以想象一下如果一个这样的页面包含复杂的业务逻辑，每当要对系统进行维护或增加新功能的时候那个酸爽～

像上面这种把界面、业务逻辑和数据模型都整合在一起的做法，从软件的设计和可维护性方面看都是极不可取的。为了解决上述问题就发展出了各种MV*框架模式（MV*理论本身是一种模式，但它的各种实现又叫MV*框架），它是通过解决M和V的耦合问题来实现界面分离。

MVC：Model-View-Controller
MVP：Model-View-Presenter
MVVM：Model-View-ViewModel

总结：可以从上面的全称可以看出无论MVC、MVP和MVVM都是围绕着Model和View，都是为了解决Model和View的耦合问题，只是实现的思想不一样而已。

MVC

MVC把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller），关系如下图所示：

模型（Model）：数据库相关的操作、文件的访问和数据结构等。

视图（View）：专注于显示，如Web前端（HTML/CSS/Java Script）

控制器（Controller）：连接模型和视图，如把视图的请求发送给模型或把数据返回给视图等

MVC只是一种框架模式，针对不同的平台环境的实现方式会有些区别：

Web MVC

经典的Web MVC模式，实现的框架有ASP.Net MVC/Spring MVC 等，在Web MVC中Model的数据通过Controller返回给View。

桌面UI MVC

经典实现有PureMVC，PureMVC 是在基于MVC模式建立的一个轻量级的应用框架。它的Model与View的交互是通过观察者模式实现的，当Model有变化要通知View的时候Model把消息发送给通知分发中心，然后通知分发中心把消息发送到View。

总结：

MVC的实现了视图和模型的分离，避免了视图和模型糅合在一起，当视图改变的时候只要业务逻辑没变不需要改变模型；但是它有一个缺点缺点是因为MVC中的控制器并不能直接更新视图，所以MVC并不能实现视图和模型的完全分离，视图依然依赖模型的数据（数据结构）来显示，也就是说视图依赖模型。

MVP

MVP是针对MVC的缺点而进行了改进，它把软件系统分为三个基本部分：模型（Model）、视图（View）和展示器（Presenter），关系如下图所示：

模型（Model）：数据库相关的操作、文件的访问和数据结构等。

视图（View）：专注于显示，如Web前端（HTML/CSS/Java Script）

展示器（Presenter）：连接模型和视图，处理视图的请求并根据模型更新视图。

总结：

MVP用展示器代替了控制器，而展示器是可以直接更新视图，所以MVP中展示器可以处理视图的请求并递送到模型又可以根据模型的变化更新视图，实现了视图和模型的完全分离。

MVVM

MVVM是MVP更进一步的发展，把软件系统分为三个基本部分：模型（Model）、视图（View）和视图模型（ViewModel），关系如下图所示：

模型（Model）：数据库相关的操作、文件的访问和数据结构等。

视图（View）：专注于显示，如Web前端（HTML/CSS/Java Script）

视图模型（ViewModel）：连接模型和视图，视图模型和视图是双休绑定的。

总结：

MVVM用视图模型代替了MVP中的展示器，视图模型和视图实现了双向绑定，当视图发生变化的时候视图模型也会发生改变，当视图模型变化的时候视图也随之变化。

MVC/MVP/MVVM都是根据不同的应用需求和应用环境逐步发展而来的，它们都有各自优缺点和适用环境。比如Web开发中因为要跨越网络通讯，如果使用MVP或者MVVM来实现代价是巨大的，因为目前来说网络数据很珍贵的资源。

转载请注明出处：http://www.cnblogs.com/keitsi/p/5764785.html