我自己理解的MVC,MVP,MVVM

写下这篇文章，以后有人问我MVC的问题，我就发给他。语言短暂，文字长存

老生常谈的发一个这种基础概念文章，应该没什么人关注吧？

对了，这篇文章长期更新。

MVC模型

MVC解决的软件模型中只解决两类显性的任务：

1. 修改数据。

   比如改动数据库中的数据，比如改变一个状态机中的状态（典型的未登录、登录中、已登录）

2. 展现内容给用户。

​MVC根据这两类任务，区分了 View 和 Model 两个角色。简单来说 View 负责一切界面展现相关的事情，Model 负责所有修改数据的问题。

那为什么要Controller这个角色？

我从这么几个方面来考虑Controller的必要性。

• View 不需要知道调用哪个Model。我们经常会改动支撑View 展示的Model。需要一个中间角色来接收 View 操作的消息，并且通知Model 产生变化的。

• 根据程序运行在什么容器中，会有一些 View 的交互以外的用户操作需要造成Model 中的数据变化。典型的比如 WebApp 中的 Url 跳转导致的 hashChange事件；Android App 中由于用户点击了 Home键导致的 onPause 事件；

​所以针对这两个方面我理解了，除了 View 和 Model 显性的处理「两类基本任务」以外。需要Controller 充当这么一个角色：

Controller 的主要职责

1. 管理界面消息和数据操作的映射关系，并充当两者间的转发者。（接受界面消息，调用数据操作）
2. 接受程序运行所处容器的事件。（由于容器的变化也是由用户导致的，比如关机、刷新页面、手机home键，所以可以说Controller也是直接接受用户操作的）。

所以这幅带有User 角色的关系图我觉得更适合描述MVC模型的关系：

Android App 中的 MVC模型：

由于Android 开发经验比较多，先说说 Android 中的 MVC个个角色具体体现在什么东西上面：

• View：从形态上来说有应用界面，弹窗界面，通知栏界面这些都是View。从实现上来说，layout，View，Button 这些都是View。
• Controller：Activity，Service都是Controller。不过在实际开发过程中，我们不想让Activity和Service中的代码太重，所以会比如在Activity 以外新增 XXController 的类。由Activity接收界面消息和系统事件（都是用户操作引起的）。由XXController 来进行 Model的实际操作。
• Model：Android 中Model 层的代码是比较重的，HTTP通信，数据本地存储，图片处理，算法计算等都得组织在这个包中。所以我们会在Model下根据功能类型做一些细分的设计模式。

Web App 中的 MVC 模型

我刚开始搞Web App 开发，不过对 MVC 在 Web App 的角色体现也有一些自己的想法：

• View：这个很明确，就是浏览器的界面了，什么表单，列表，文本框，都是View。
• Controller：在WebApp 中由于 View 在客户端 Model 在服务端。所以这个Controller分两半说，在前端的部分，接受dom和window的事件的部分就是Controller。再比如我用的Webx这个MVC的web框架，支持的velocity模板中，可以在表单中指定服务端响应表单的action类是什么，这也是controller角色的体现。而在服务端部分，典型的 Serlvet接受 Tomcat 等容器的消息，所以也是controller的一部分。
• Model：这部分就是比如Servlet接收到请求后的数据处理部分了。

MVP 模型

​不管是MVP还是MVVM模型，都是MVC模型的一种演化形式。从本质上来说两个显性的任务不会变化：

1. 修改数据。
2. 展现内容给用户。

​MVP中关键是把 Controller 换成了 Presenter。Presenter 的中文含义就是主持人的意思。所以其实MVP的关键就是View 和 Model 不会 直接联系，所有调用都会通过 Presenter 来进行。

这还是我看了阮一峰大神的文章才有体会

​当然这种隔离关系不是需要开发者自己来刻意维护的。而是你使用的MVP框架的实现为开发者完成了隔离。遵循框架的规则就能实现隔离。

​所以MVC模型中，View 和Model 是有直接联系的咯？是这样的，由于MVC模型不强调VIew不能调用Model，所以开发者很容易实现View直接调用Model的逻辑。比如我们会直接在View 中创建一个监听数据变化的listener注册到Model中，这样在Model的数据变化时，View就是直接的改变。这样看起来很轻量化，但是实际上Model是常驻的，而View是暂时的，随着界面的销毁、刷新等，View需要手动注册和注销这个监听，这方面的管理也是非常麻烦的。

MVVM模型

​MVVM又是基于MVP的一种演化，关键在于 Presenter换成了 ViewModel。字面上看Model是进行数据的处理的，ViewModel就是界面层数据处理的。这样看没错。

​具体来说MVVM模型的关键，在于View的变化会直接体现在ViewModel中。当然这种直接体现，就是MVVM框架来实现的。这种变化的直接体现的好处，在于开发者开发View中的显示逻辑和VM中调用model的业务逻辑可以隔离的非常好，不需要在View中还去调用ViewModel。