前端---对MVC MVP MVVM的理解

就需要从前端这些年的从无到有、从有到优的变迁过程讲一下。

1. Web1.0时代

在web1.0时代并没有前端的概念，开发一个web应用多数采用ASP.NET/Java/PHP编写，项目通常用多个aspx/jsp/php文件构成，每个文件中同时包含了HTML、CSS、JavaScript、c#/Java/PHP代码，系统整体架构可能是这样子的：

我们可以看到服务端是比较重的，有一块既在客户端又在服务端，jsp是在我们server端生成的，然后他调用我们的service获取数据，然后在jsp页面进行封装，最后再把html前端的代码混成一个直接返回给前端。
所以我们可以看到这种架构的模式比较简单，而且很快捷。
但是缺点也很明显：jsp代码难以维护（前端代码和后端代码是混在一起的，如果业务逻辑复杂一些这个代码应该是非常庞大的）

2. MVC开发模式

为了让开发更加的快捷，代码更容易维护，前后的职责更清晰一些（不要把代码混在一起），就衍生出来了MVC开发模式和框架，前端展示以模型的形式出现。典型的框架就是Spring、Structs、Hibernate。整体框架如图所示：

他们的目标就是把我们的视图、数据和业务逻辑控制分层，这样代码也就分层了。
使用这种分层架构、职责清晰，代码容易维护。但是这里的MVC仅限于后端，前后端形成了一定的分离，前端只完成了后端开发中的view层。
那时候的前端程序员只是写一些前端页面和少量的js代码进行交互，但是仅限于静态页面，没有数据，然后再把这个页面交给后端程序员，后端再拿模版语法对他进行动态化的改造。

但是这种模式也存在着一些问题：

1. 前端页面开发效率不高（主要把图变成静态页面然后交给后端）
2. 前后端职责不清

3. Web 2.0

自从Gmail的出现，ajax技术风靡全球，有了ajax之后，前后端的职责就更加清晰了。因为前端可以通过ajax与后端进行数据交互，因此整体的架构图就变成了下幅图：

通过ajax与后台服务器进行数据交互，前端开发人员只需要开发页面这部分内容，数据可由后台进行提供。而且ajax可以使页面实现部分刷新，减少了服务端负载和流量消耗，用户体验更好。这时候才有了专职的前端工程师。同时前端的类库也慢慢的发展，最著名的就是jQuery了。
当然此架构也存在一些问题：缺乏可行的开发模式承载更复杂的业务需求，页面内容都糅杂在一起，一旦应用规模增大就难以维护。因为前端的MVC也随之而来。

4.前后端分离后的架构演变–MVC、MVP、MVVM

1. MVC

前端的MVC与后端的类似，具备着View、Controller和Model

Model：负责保存应用逻辑，与后端数据进行同步（专门用来封装和处理数据的）
Controller：负责业务逻辑，根据用户行为对Model数据进行修改（专门来处理请求的，1.接收参数 2.调用service层代码 3.控制页面跳转）
View：负责视图展示，将model中的数据可视化出来 好处：奇强调责任分离，方便维护代码

三者形成了一个模型：

这样的模型在理论上是可行的，但是在开发的过程中并不会这么操作。因为开发过程不灵活，例如：一个小小的事件操作都必须经过这么一个流程，那么开发就不在便捷了。

在实际场景中，我们往往会看到另外一种模式，如图：

这种模式在开发中更加的灵活，backbone.js框架就是这种模式。

但是这种灵活可能导致严重的问题：

1. 数据流混乱（数据再发生变化时不知道是谁变的，在做维护的时候找问题就不好查）
   
2. View比较庞大，但是Controller比较单薄（一些简单的数据监听，然后直接调用Model层的更改逻辑，可有可无）：由于很多的开发者都会在view中写一些逻辑代码，逐渐的就导致view中的内容越来越庞大，而controller变得越来越单薄。

既然有了缺陷就会有变革，前端的变化中似乎少了MVP的这种模式，是因为Angular早早地将MVVM框架模式带入了前端，MVP模式虽然在前端开发模式中不常见，但是在安卓等原生开发中，开发者还是会考虑它的。

2.MVP

MVP模式与MVC很接近，P指的是presenter，我们可以理解为一个中间人，他负责着View和Model之间的数据流动，防止二者之间的直接交流，我们可以看一下图示：

我们可以看到presenter负责和Model进行双向交互，还和View进行双向交互。这种交互方式相对于MVC来说少了一些灵活，View变成了被动视图，并且本身变得很小。虽然他分离了View和Model，但是应用逐渐变大之后导致presenter的体积变大，难以维护。如果想解决这个问题，我们可以从MVVM的思想中找到答案。

3.MVVM（Model-View-ViewModel）

ViewModel可以理解成是Presenter的进阶版

M（model）：专门来准备数据的
V（View）：展示页面
VM（ViewModel）：视图和模型（视图和模型的转换）：他是DOM监听器，监听着页面dom节点的变化，当页面DOM节点发生改变的时候，数据也会发生对应的改变

双向绑定机制：

• ViewModel通过实现一套数据响应式机制自动响应Model中数据的变化（绑定数据：当model数据发生变化的时候，对应的界面也会发生改变）
• 同时ViewModel会实现一套更新策略自动将数据变化转换成视图更新（DOM监听器，监听着页面dom节点的变化，当页面DOM节点发生改变的时候，数据也会发生对应的改变）
• 实现数据绑定的方法有多种，常见的有观察者模式和发布-订阅模式。

通过事件监听响应View中用户交互修改Model数据
这样在ViewModel中就减少了大量的DOM操作代码
MVVM在保持View和Model松耦合的同时，还减少了维护他们关系的代码，使用户专注于业务逻辑，兼顾开发效率和可维护性。

5.总结

• 这反映了前端领域的发展进程，这三者都是框架模式，它们设计的目标都是为了分层：解决Model和Viev的耦合问题。
• MVC模式出现较早主要应用在后端，如Spring MVC、ASP.NET MVC等，在前端领域的早期也有应用，如Backbone.js，它的优点是分层清晰，缺点是数据流混乱，灵活性带来的维护性问题。
• MVP模式在是MVC的进化形式，Presenter作为中间层负责MV通信，解决了两者耦合问题，但P层过于臃肿会导致维护问题。
  -MVVM模式在前端领城有广泛应用，它不仅解决MV耦合问题，还同时解决了维护两者映射关系的大量繁杂代码和DOM操作代码，在提高开发效率、可谈性同时还保持了优越的性能表现。