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

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操作代码,在提高开发效率、可谈性同时还保持了优越的性能表现。

点赞(0) 打赏

评论列表 共有 0 条评论

暂无评论

微信公众账号

微信扫一扫加关注

发表
评论
返回
顶部