关于MV*模式的一己之见，科普向

一直对mv*模式不太了解，终于趁着周末闲暇之余试着去理解了如下，如下是我的总结，欢迎讨论，若有错误请指教。

初

传统mvc

mvc是一套设计模式的组合，最初是用于解决客户端图形界面应用程序的模块化问题。

因为用户界面逻辑的更改每每要比业务逻辑更频繁，而且在某些状况下，应用程序须要以不一样的方式来显示同一数据等...诸多问题下，解决方案mvc就此诞生。

Model-View-Controller (MVC) 将程序划分为三层

• 模型 model封装了程序指定的数据和逻辑（数据与业务）

• 视图 view是对数据的显示（界面）

• 控制器 controller可以响应用户操做来通知model进行更新（只是通知，真实处理是由model自身执行）或者view的更新（事件）

model不仅是数据的整合，还包含了对数据进行处理的能力。

三者依赖和调用关系能够参考下图，主要是懒得画。

依赖：能够很明确的看到view和controller都依赖于model。

调用：

1. view接收到输入，转发给controller
2. controller 对输入进行预处理后，调用匹配的model接口
3. model执行业务逻辑，变动数据后经过观察者/订阅模式通知全部已注册的观察者（view）
4. view收到model变动通知，请求更新后的数据，更新界面
复制代码

关于调用关系能够看出，mvc主要由观察者模式构筑，策略模式（controller能够算做view的策略之一）以及其余模式做为辅助

依赖关系能够在调用流程中获得验证，view因为是直接向model请求数据并更新的，因此view实质上是知道model内数据的相关结构的，controller同理。这就致使了view与controller没法脱离model，而且不可在其余程序内部复用。

被动mvc

时代的发展，致使如今web应用的大行其道。

与客户端图形界面程序不一样，web应用主要是经过http协议进行通讯，但http协议是单工协议而且是无状态的，服务器没法直接给客户端推送数据，这也就致使了view订阅model更新的模式被打破。

变动后web应用mvc模式大体流程为：

1. 客户端发送请求
2. 服务端经过路由调用相应的controller ，对来自客户端得请求进行格式化预处理而后调用相应的 model 接口
3. model执行业务逻辑，使用数据渲染模版视图，服务器回复请求
5. 客户端更新
复制代码

演化

mvp

因为mvc模式下的view与model的高度耦合，view没法被组件化，复用程度低，因此mvp被提出

mvp直接切断了view和model的绑定关系，解除了两者的耦合。

controller 被替换（重命名）成了 presenter

mvp调用改变为：

1. view接收到输入，转发给presenter
2. presenter对输入进行预处理后，调用匹配的model接口
3. model执行业务逻辑，变动数据后经过观察者模式通知presenter
4. presenter获取更新后的数据，经过view提供的更新接口更新进行界面更新
复制代码

实质上mvp就是mvc的另外一形式，presenter相比controller包含了更多的逻辑变得厚重（接受model的变动通知，与更新view的能力）。而view再也不依赖model，对于model以及presenter内的数据与业务彻底无感知，因此view能够被抽象用于不一样的应用中，只要提供对应的接口。

mvvm

mvvm是mvp的改良版，相对于mvp而言，在依赖关系上与调用关系上都没有什么变化，因此就不放图了:)

mvp相比mvc来讲，它抽离了view提升了模块化程度，但presenter层既承担了对view事件的预处理，又须要提供对于view的数据同步，致使了逻辑过于繁琐厚重，难以开发与维护。

因而Model-View-ViewModel被提出，vm承载了presenter的功能，而且将model与view之间的数据更新抽离出来，提供了自动化的能力，开发人员没必要再手动维护model与view之间的更新逻辑，能够更专一于核心业务的开发。

mvc => mvp => mvvm 模式的更新，本质上是因为项目复杂度不断增长，新的需求被不断被提出，为了维持现状而被迫的升级改良。

新模式这方面，新模式是不可能有新模式的，这辈子不可能有新模式的。换模式又不会搞，就是改良模式这种东西，才能维持的了生活这样子。

前端

终于到前端了，做为本职工做，前端战五渣，虽然不懂，但仍是要勉强一写，关于模式的理论在上文中已经大体介绍了一遍，下面只是一些关于模式与前端框架的杂谈。

前端框架与库千千万，模式却很少，也就mvc与mvvm占主流。

Angular与Vue能够算是主流的mvvm框架/库，因为Angular只是浅显的走过一次教程因此就不提了。

Vue

关于Vue，在我看来，框架自身能够算是一层vm，至于咱们写的模版，天然是view。但有不少人认为model应该是data也就是数据。但我认为，开发人员所写的js大多都属于model。

Vue的实现能够分为两步，对数据的劫持与解析dom后的数据监听（订阅者），实现了一套data=>view，view=>data的关系，用于自动化处理数据，开发者无需关注dom的更新，只须要为对应的事件来编写匹配的，用于更新data的函数便可（包含了ajax对于后端的请求）。

先后端分离的模式下，后端基本上只须要提供RESTful API便可。

React

React 起源于 Facebook 的内部项目，由于该公司对市场上全部 JavaScript MVC 框架，都不满意，就决定本身写一套，用来架设 Instagram 的网站。

React应该是一个属于mvc的视图库，功能很是简单而纯粹，根据state渲染view。

末

关于react没有多写，第一是感受言尽于此，描述的挺清楚的。其次是由于写这篇总结纯属意外，原本前两天在看一些flux实现与redux源码（才四五百行，注释都还写的挺清楚，对react有兴趣的朋友能够看看）而后莫名其妙就开始看mvc相关内容，跑偏了，后面就放弃治疗了。

若是有机会的话，下一篇估计会写关于flux=>redux的文章，react留到下一篇再聊。

---

参考资料以下。

微软msdn：MVC模式

阮一峰：谈谈MVC模式

阮一峰：MVC，MVP 和 MVVM 的图示

百度文库：深刻浅出设计模式之MVC

界面之下：还原真实的MV*模式