gpt4 book ai didi

MVC,MVP,MVVM

转载 作者:知者 更新时间:2024-03-13 05:49:07 32 4
gpt4 key购买 nike

当我们在面试的时候被问到谈谈你对MVC,MVP,MVVM的理解。我们该如何回答,下面我们将对这些模式进行总结。
一、web1.0时代
web1.0时代,当时并没有前端这个概念,当时如果要开发一个项目,通过java/php/.net进行开发,项目通常由多个aspx/jsp/php文件编写,每一个文件同时包含html,css,js,c#/java/php代码,系统架构如下所示。

这种架构的好处就是简单快捷,但是缺点是jsp代码难以维护。
为了让开发快捷,然后代码更加易于维护,现在后端衍生了MVC模式,前端展示以模板的形式出现,此时前后端职责更加清晰,代码也易于维护。此时前端只完成后端MVC模式下的view层。具体如下所示。

此时这种开发模式中存在的缺点就是前端的开发效率不高。
二、web2.0时代
自动ajax的出现,前后端的职责就更加清晰,此时前端可以通过ajax和后台进行交互,因此,整体架构图可以如下所示。

通过ajax与后台服务器进行数据交互,前端开发人员只需要编写相关的代码,数据完全由后台进行提供,并且ajax可以实现异步刷新,减少服务器载荷,此时才出现真正意义上的前端工程师。但是此时在前端一些任何代码都写在一起,不利于前端的后期维护。此时前端也开始存在自己的MVC架构。
三、前后端分离后的架构演变——MVC
前端的MVC和后端的类似,具备这ViewControllermodel
view:负责保存应用数据,与后端数据进行同步。
controller:负责业务逻辑,根据用户行为对model数据进行修改。
view:负责视图逻辑,将model中的数据可视化出来。

但是在开发中,我们经常会看到另一种模式,如下图所示。

这种模式在开发中更加灵活,但是也存在一些问题。
1、数据流比较混乱,如上图所示,我们view可以更改model中的数据,controller可以更改model中数据,此时我们无法确定model中的数据是被谁更改的,更无法追中。
2、controller比较单薄,view比较庞大:我们会更加喜欢直接通过view来修改model中的数据,所以更多的代码会放在view模块中,导致view中的数据比较庞大。
四、前后端分离后的架构演变——MVP
MVPMVC很接近,P指的是Presenterpresenter可以理解为中间人,它负责着viewmodel之间的数据流动,防止viewmodel之间直接交流。如下图所示。

presenter为中间层,这种交互方式相比于MVC少了一些灵活,并且此时的view的体积要小很多,相反presenter的代码体积就大的多,导致代码难以维护。
五、前后端分离后的架构演变——MVVM
首先何为MVVMMVVM可以分解为Model-view-ViewModel,可以理解为在presenter上的进阶版。

viewModel通过实现一套数据响应式机制自动响应model中的数据变化。
同时viewModel会实现一套更新策略自动数据变化更新视图。
通过事件监听响应view中的用户交互修改model中的数据。
这样在viewModel中就减少操作大量的DOM
MVVM在保持viewmodel松耦合得同时,还减少了维护他们关系的代码,使用户更加专注于业务逻辑,兼顾开发效率和维护。
六、总结
这三种都是框架模式,他们的目标都是为了解决modelview之间的耦合度问题。
MVC模式出现较早主要应用在后端,如spring MVC,等,在前端领域早期也有应用,如Backbone.js,他的优点是分层清晰,缺点是数据流混乱,并且灵活性带来了难以维护的问题。
MVP模式在是MVC的进化形式,Presenter作为中间层负责MV之间的通信,解决两者耦合问题,但p层过于臃肿会导致维护问题。
MVVM模式在前端领域有广泛的应用,它不仅解决MV耦合问题,还解决了在维护MC之间的关系产生了大量代码的问题,提高了开发效率和可读性。

32 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com