掌握MVC,MVP,MVVM设计模式原理 您所在的位置:网站首页 mvc页面生命周期 掌握MVC,MVP,MVVM设计模式原理

掌握MVC,MVP,MVVM设计模式原理

2023-03-30 11:40| 来源: 网络整理| 查看: 265

MVC

MVC全名为Model View Controller ,是模型(Model)- 视图(View)- 控制器(Controller)的缩写。

Model层:模型(用于封装业务逻辑相关的数据以及对数据的操纵) View层:视图(渲染图形化界面,也就是所谓的UI界面) Controller层:控制器(M和V之间的连接器,主要处理业务逻辑,包括显示数据,界面跳转,管理页面生命周期等) MVC 当有用户的行为触发操作时,控制器(Controller)更新模型,并通知视图(V)和模型(M)更新,这时视图(V)就会向模型(M)请求新的数据,这就是标准MVC模式下Model,View 和 Controller 之间的协作方式。 MVC优点: 耦合性低,视图层和业务层分离,这样就允许更改视图层代码而不用重新编译模型和控制器代码。 重用性高 生命周期成本低 MVC使开发和维护用户接口的技术含量降低 可维护性高,分离视图层和业务逻辑层也使得WEB应用更易于维护和修改 部署快 MVC缺点: 不适合小型,中等规模的应用程序,花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。 视图与控制器间过于紧密连接,视图与控制器是相互分离,但却是联系紧密的部件,视图没有控制器的存在,其应用是很有限的,反之亦然,这样就妨碍了他们的独立重用。 视图对模型数据的低效率访问,依据模型操作接口的不同,视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问,也将损害操作性能。 MVP

MVP全名为Model View Presenter ,是由MVC演变而来,它和MVC的相同之处在于:Controller / Presente都是负责业务逻辑,Model管理数据,View负责显示。不过在MVP中View并不直接与Model交互,它们之间的通信是通过Presenter (MVC中的Controller)来进行的,即使用 Presenter 对视图和模型进行了解耦,让它们彼此都对对方一无所知,沟通都通过 Presenter 进行。

Model层:模型(用于封装业务逻辑相关的数据以及对数据的操纵) View层:视图(渲染图形化界面,也就是所谓的UI界面) Presenter层:控制器(M和V之间的连接器,主要处理业务逻辑,包括显示数据,界面跳转,管理页面生命周期等)

在 MVP 中,Presenter 可以理解为松散的控制器,其中包含了视图的 UI 业务逻辑,所有从视图发出的事件,都会通过代理给 Presenter 进行处理;同时,Presenter 也通过视图暴露的接口与其进行通信。

MVP MVP特点: M、V、P之间双向通信。 View 与 Model 不通信,都通过 Presenter 传递。Presenter完全把Model和View进行了分离,主要的程序逻辑在Presenter里实现。 View 非常薄,不部署任何业务逻辑,称为”被动视图”(Passive View),即没有任何主动性,而 Presenter非常厚,所有逻辑都部署在那里。 Presenter与具体的View是没有直接关联的,而是通过定义好的接口进行交互,从而使得在变更View时候可以保持Presenter的不变,这样就可以重用。不仅如此,还可以编写测试用的View,模拟用户的各种操作,从而实现对Presenter的测试–从而不需要使用自动化的测试工具。 MVP优点: 模型与视图完全分离,我们可以修改视图而不影响模型; 可以更高效地使用模型,因为所有的交互都发生在一个地方——Presenter内部; 我们可以将一个Presenter用于多个视图,而不需要改变Presenter的逻辑。这个特性非常的有用,因为视图的变化总是比模型的变化频繁; 如果我们把逻辑放在Presenter中,那么我们就可以脱离用户接口来测试这些逻辑(单元测试)。 MVP缺点: 视图和Presenter的交互会过于频繁,使得他们的联系过于紧密。也就是说,一旦视图变更了,presenter也要变更。 MVVM

MVVM全名为Model View ViewModel ,早在 2004 年,Martin Fowler 发表了一篇名为 Presentation Model (以下简称为 PM 模式)的文章,PM 模式与 MVP 比较相似,它从视图层中分离了行为和状态;PM 模式中创建了一个视图的抽象,叫做 Presentation Model,而视图也成为了这个模型的『渲染』结果。MVVM 与 Martin Fowler 所说的 PM 模式其实是完全相同的,Fowler 提出的 PM 模式是一种与平台无关的创建视图抽象的方法,而 Gossman 的 MVVM 是专门用于 WPF 框架来简化用户界面的创建的模式;我们可以认为 MVVM 是在 WPF 平台上对于 PM 模式的实现。 WPF(Windows Presentation Foundation – 微软推出的基于Windows 的用户界面框架)

MVVM 作为 Martin Fowler 在 2004 年提出的概念,Presentation Model 到今天其实也是非常先进的,PM 模式将视图中的全部状态和行为放到一个单独的展示模型中,协调领域对象(模型)并且为视图层提供一个接口。在监督控制器(Controller)中,视图层与模型层中的一些简单属性进行绑定,在模型属性变化时直接更新视图(耦合),而 PM 通过引入展示模型将模型层中的数据与复杂的业务逻辑封装成属性与简单的数据同时暴露给视图,让视图和展示模型中的属性进行同步。这样看起来好像与MVP差别不大,其实两者最大的区别就在于视图和展示模型之间状态的同步,即类似于前端Vue框架中的数据双向绑定,不再是调用中间层的接口。这里通过Vue中的一个小例子就能明白:

Document 点击提交 {{item}} var app = new Vue({ el: '#app', data: { list: [], inputValue: '' }, methods: { handleClickon: function() { this.list.push(this.inputValue); this.inputValue = ''; } } })

可以看到当我们在控制台(可以看成VM)处理数据时,可以立即更新到视图上(V),而在视图上输入时(V),也可以在控制台同步看到(VM),这就是双向数据绑定,也是MVVM与MVP的区别之处。

MVVM优点:

MVVM模式和MVC模式类似,主要目的是分离视图(View)和模型(Model),有几大优点:

低耦合,视图(View)可以独立于Model变化和修改,一个ViewModel可以绑定到不同的”View”上,当View变化的时候Model可以不变,当Model变化的时候View也可以不变。 可重用性,可以把一些视图逻辑放在一个ViewModel里面,让很多view重用这段视图逻辑。 独立开发,开发人员可以专注于业务逻辑和数据的开发(ViewModel),设计人员可以专注于页面设计,使用Expression Blend可以很容易设计界面并生成xml代码。 可测试,界面向来是比较难于测试的,而现在测试可以针对ViewModel来写。 总结:

从 MVC 架构模式到 MVVM,从分离展示层到展示模型层,经过几十年的发展和演变,MVC 架构模式出现了各种各样的变种,并在不同的平台上有着自己的实现。 在架构模式的选用时,我们往往没有太多的发言权,主要因为平台本身往往对应用层有着自己的设计,我们在开发客户端或者前端应用时,只需要遵循平台固有的设计就可以完成应用的开发;不过,在有些时候,由于工程变得庞大、业务逻辑变得异常复杂,我们也可以考虑在原有的架构之上实现一个新的架构以满足工程上的需要。 各种架构模式的作用就是分离关注,将属于不同模块的功能分散到合适的位置中,同时尽量降低各个模块的相互依赖并且减少需要联系的胶水代码。文中对于 MVC、MVP 和 MVVM 架构模式的描述很难不掺杂作者的主观意见,如果对文章中的内容有疑问,欢迎提出不同的意见进行讨论。



【本文地址】

公司简介

联系我们

今日新闻

    推荐新闻

    专题文章
      CopyRight 2018-2019 实验室设备网 版权所有