MVC

mvc其实是从后端mvc架构模式中演变而来的,在2005年之前,也就是ajax还没有出现在前端世界中的时候,页面的处理其实都是由后端一人完成,全栈大师,那会前端技术还是很简单的,后端一个人就能实现从数据库拿数据然后渲染成一个完整html页面返回给浏览器。

但是就是这个过程耦合度很高,以至于不太好维护代码,于是采用了一种分层模式,将不同的代码分为不同的部分,也就是解耦处理,总共分为三层:模型层(Model)、视图层(View)、控制器层(Controller)。

模型层就是数据库的模型,如果使用过面向对象的数据库框架,比如sequelize,他们将每一个数据库的表转换成一个对象,通过操作这个对象的方法和属性实现对数据的改写,这个对象被称为模型。

视图层在那时其实是通过模板引擎来渲染html文本的,先通过控制器获取模型的数据,然后将变量放入模板中,模板编译后生成html文件返回给浏览器渲染。

控制器用于连接视图层和模型层,提供获取视图数据的方法,调用视图模板生成html返回给浏览器,属于一种沟通作用。

随着2005年2月的ajax发布,加上前端的知识越来越多,光后端一个人处理已经做不到了,加上ajax的出现,前端可以通过请求的方式获取到数据,已经不需要和后端混在一起开发了,于是出现了真正意义上的前后端分离开发。

前端分离后,前端也是需要处理代码的维护性,于是借鉴了后端的mvc分层架构模式,衍生了自己的mvc。

前端的模型层,其实真正意义上是获取数据的对象,它可以通过ajax异步请求获取数据,然后对数据进行处理。

而视图层大部分都是定义为一个返回html字符串的函数

控制器用于连接模型层和视图层,响应dom操作,给视图层提供模型层的数据,承载业务逻辑。

理论很美好,但是在实际开发过程中,mvc更像是理论上的抽象,各家对mvc的实现都有不同,比如view层可以和model层直接沟通,并没有经过Controller层,因为前端不像后端,前端需要考虑用户交互的问题,代码的实现上也会有不同。

后端每次都是通过唯一的url地址,在路由中将对应的新html页数据返回,返回后不关心也无法关心页面了,前端则是需要响应各种变化做对应的处理,完全的遵循mvc的模式其实并没有很适用。

最终演变来的问题是:

  1. model层与view层通信问题,需要通过控制层隔离吗?还是直接通信,通信是单向还是双向?
  2. 控制器需要完成哪些功能,是简单的关联性流程调度,还是更加复杂的处理?

MVP

于是在mvc各种实现之后,提出来了一个新的模式,就是mvp,它将model与view隔离,通过Presenter层进行沟通,用户的操作逻辑也都在Presenter层中。

三层定义:

  1. Model层:提供操作数据的接口
  2. View层:提供更新视图的接口,当用户有行为发生时触发事件
  3. Presenter层:定义用户的交互逻辑与流程,但所有与数据操作和视图的更新都通过调用Model层与View层的接口实现,注册View层事件。

通过事件订阅模式解决层与层之间的强耦合。

这里其实已经能看到现在开发模式的雏形了,mvp把view和model抽象后只留下了接口,并且把业务逻辑全部封装到Presenter层中,但是此时的Presenter层需要做的事情有很多,它需要处理事件订阅,需要处理数据响应,以及复杂的业务代码,并不纯粹,而且体积非常庞大。

MVVM

这是我们现在使用了架构模式,他是三个部分:M - V -VM(ViewModel);很多人可能会以为是4个部分。

在mvvm中,vm的处理是无形的,他将事件绑定,数据的响应式做成了一套规则体系,不需要在手动去处理数据源的变化订阅,当model的数据发生变化,vm会自动将其映射到view层,反之view的变化也会自动映射到model层的数据。

简单点来说就是由数据驱动的模式,将繁琐的部分都给剥离出去,开发者能更加专注的处理业务逻辑。

总结

由于本人并没有经历过mvc和mvp的时代,所以很多东西都是懵懂的,特别是view层和model层为啥会耦合,等我有机会了解了再来细说一下。

总的来说简单了解了三种模式后,可以看出这其实是应对不同时代的需求所衍生出的解决问题的方式,也许以后会有更好的模式也说不定,总之以目前的能力,浅尝即可。

感谢这篇文章:《从MVC在前端开发中的局限性谈起》

不知道是不是真正的出处,先贴上吧

分类: 设计模式 标签: mvcmvpmvvm

评论

暂无评论数据

暂无评论数据

目录