MVC-MVP-MVVM

本文详细介绍了MVC、MVP和MVVM三种软件开发架构模式,探讨了它们的历史、基本思想、区别与相似点。MVC强调业务逻辑集中在Controller,MVP通过Presenter解耦View与Model,而MVVM则通过双向数据绑定让ViewModel协调View与Model。每种模式都有其适用场景,理解它们有助于提升软件设计与团队协作效率。
摘要由CSDN通过智能技术生成

MVC

MVC是有一定历史的架构了,它分为model-view-controller,它用一种业务逻辑、数据、界面显示分离的方法组织代码,将业务逻辑聚集到一个部件里面,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

最典型的MVC就是之前学习的jsp+servlet+javabean模式。

JavaBean作为模型,既可以作为数据模型来封装业务数据,又可以作为业务逻辑模型来包含应用的业务操作。其中,数据模型用来存储或传递业务数据,而业务逻辑模型接收到控制器传过来的模型更新请求后,执行特定的业务逻辑处理,然后返回相应的执行结果。

JSP作为表现层,负责提供页面为用户展示数据,提供相应的表单(Form)来用于用户的请求,并在适当的时候(点击按钮)向控制器发出请求来请求模型进行更新。

Serlvet作为控制器,用来接收用户提交的请求,然后获取请求中的数据,将之转换为业务模型需要的数据模型,然后调用业务模型相应的业务方法进行更新,同时根据业务执行结果来选择要返回的视图。

MVP

MVP 是从经典的模式MVC演变而来,它分为Model-View-Presenter,它们的基本思想有相通的地方:Controller/Presenter负责逻辑的处理,Model提供数据模型,View负责页面交互。

MVC-MVP区别:在MVP中View并不直接使用Model,它们之间的通信是通过Presenter (MVC中的Controller)来进行的,所有的交互都发生在Presenter内部,而在MVC中View会直接从Model中读取数据而不是通过 Controller。在MVC里,View是可以直接访问Model的!从而,View里会包含Model信息,不可避免的还要包括一些业务逻辑。 在MVC模型里,更关注的Model的不变,而同时有多个对Model的不同显示,即View。所以,在MVC模型里,Model不依赖于View,但是View是依赖于Model的。不仅如此,因为有一些业务逻辑在View里实现了,导致要更改View也是比较困难的,至少那些业务逻辑是无法重用的。虽然 MVC 中的 View 的确“可以”访问 Model,但是我们不建议在 View 中依赖 Model,而是要求尽可能把所有业务逻辑都放在 Controller 中处理,而 View 只和 Controller 交互。这么耦合性就降低了。

MVVM

MVVM也是从经典的模式MVC演变而来,它分为Model-View-ViewModel。View绑定到ViewModel,然后接受命令做出页面调整同时在向它请求一个动作。同样,ViewModel跟Model通讯,Model发生了数据改变通知页面调整同时ViewModel告诉它更新来响应UI请求。这样便使得为应用构建UI非常的容易。界面构建越容易,外观设计师就越容易创建一个漂亮的界面。同时,当UI和功能越来越松耦合的时候,功能的可测试性就越来越强。

MVP和MVVM相同点:他们的优势都是降低了系统的耦合性,但同样也保证了各个层的功能高聚合。架构设计清楚,功能明确之后对于团队协作也很有帮助——因为M层和V层低耦合,那么这两块的工作量完全可以分开。对于复用性也更有目标了——视图层一些基础的操作封装和各个视图层的组合,数据模型层可以用不同的视图层去展示和各个数据模型的组合。低耦合也更有利于单元化测试。

关于MVP和MVVM的区别:我在实现了两种模式之后发现他们应该是侧重的方向不一样,解决问题的目标是一致的,都是想尽量解耦Model层和View层,但是方式不一样。他们最大的不同是P层和VM层所扮演的角色,presenter主要是针对业务逻辑进行梳理将Model、View完全分离解耦,在Presenter层添加M层、V层的实例来处理业务逻辑。而ViewModel主要是针对视图状态和行为进行抽象和绑定,也是将V和M层分离解耦,但是VM层并不是按照对应的业务逻辑进行拆分,而是将V层和M层做一个关联关系的绑定——制定出一套绑定规则让他们去遵守,VM维护的是他们的沟通规则,比Presenter更“抽象”一些。比较好的VM层其实是可以抽象提炼出来的。比如Android的DataBinding Library,他制定出了一套规则,让使用者不需要知道他们(View、Model)是怎么关联的,也不用写VM层的具体实现,只需要按照规则写好View层和Model层的相关代码,DataBinding会自动生成关于VM的代码,这就很好的体现出他是一套“高级”的规则的“优势”。对于一些代码“”控制欲“较强的人还是推荐MVP,如果是用官方DataBInding实现的MVVM在“控制”方面可能不是那么强,毕竟代码很多都是工具生成的。至于我看网上有些人建议的开发可以结合两者MVP和MVVM能更完美,可能是对代码量没要求、对代码控制欲较强的开发者来说更好吧,后面在具体应用中多体会体会这两种模式带来的更多感觉吧。

这篇博客在我的简书里也转载了,欢迎前去观看讨论。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值