MVC,MVP,MVVM都是用来解决界面呈现和逻辑代码分离而出现的模式。
一.MVC、MVP、MVVM诞生的需求
我们所有的代码都是围绕数据的。
围绕数据的产生、修改等变化,出现了业务逻辑。
围绕着数据的显示,出现了不同的界面技术。
没有精心设计的代码常常会出现数据层(持久层)和业务层还有界面代码耦合的情况。
ORM等框架,降低了业务逻辑和数据之间的耦合,业务逻辑不再关心底层数据如何存储和读取。所有数据呈献给业务逻辑层的就一个个的对象。
MVC,MVP,MVVM就是用来解决业务逻辑和视图间的耦合的。
二、MVC模式
Model View Controller 模型视图控制器的缩写,MVC开始是存在桌面程序中的,M是指业务模型,V是指用户界面,C则是控制器,使用MVC的目的是将M和V的实现代码分离,从而使同一个程序可以使用不同的表现形式
3.1 主动MVC
model主动通知view更新
model:用于封装与应用程序的业务逻辑相关数据以及对数据的处理方法。模型中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制,这些用于监视此模型的视图必须事先在此模式上注册,从而,视图可以了解数据模型上发生的改变
view:负责数据的展示。
在视图中一般没有程序上的逻辑。为了实现视图上的刷新功能,视图需要访问它监视的数据模型,因此应该实现在被它监视的数据那里订阅model事件
Controller:控制器是M和V之间的连接器,用于控制应用程序的流程。它处理事件并作出响应。事件包括用户的行为和数据模型上的变化。
3.2被动MVC
与主动MVC的区别是view没有订阅model数据变化的事件,等待model来通知需要根据新的数据来更新view,被动MVC中,Controller负责通知view,有数据变化,需要更新视图
被动MVC与主动MVC的区别
1、模型对视图和控制器一无所知,它仅仅是被它们使用
2、控制器使用视图,并通知它更新数据显示
3、视图仅仅是在控制器通知它去模型取数据的时候它才这么做
3.3web应用中的MVC框架
Web中的MVC框架都是被动MVC模式,因为web应用中,由于http是基于请求和响应方式协同工作的,因此当服务器端的model发生变化时,它不会立即更新客户端的view,只有客户端重新请求或刷新界面时才更新
3.4MVC总结
MVC优点
由于MVC很好地分离了视图层和业务层,所以它具有以下优点:
耦合性低
开发速度快
可维护性高
没有控件的概念,对HTML没有封装,易于理解
和其他平台等更加相似
误区:
1、把model理解成实体类,在MVC中Model应该包含2部分功能,一部分是处理业务逻辑,一部分是提供view显示的数据
2、把业务逻辑全部放在Controller端
Model在MVC架构中起的作用非常重要,它应该是业务逻辑真实地实现层。所以Model的实际上是business Model。而Controller仅仅起一个桥梁作用,负责把view的请求转发给Model,再负责把Model处理结束的消息通知view。Controller是用来解耦view和Model的,具体一点说,就是为了让UI与逻辑分离。
三、MVP模式
MVP模式也是一种经典的界面模式。MVP中的M代表Model,V是View,P是Presenter。
1、MVP的思想
MVP模式在我看来,是一个真正意义上的隔离View的细节和复杂性模式。为什么这么说:因为在其它模式中V代表的石UI界面,是一个html页面,XAML文件或者winform界面。但是在MVP模式中的V代表的是一个接口,一个将UI界面提炼而抽象出来的接口。接口意味着任何事先了该接口的界面都能够复用已有的Presenter和Model代码。
2、UI界面接口化
后端代码要获取界面上的输入框的值,只需要get属性,要更新界面显示的时候,就只需要set属性。
后端代码对于界面的操作,被抽象成了对于UserAge属性的操作了,也就是和具体的界面显示无关。
3、Presenter--Model和View之间的桥梁
P是Model和View之间的桥梁,负责将对应的Model和View组合到一起
4、MVP模式总结
在MVP里,Presenter完全把Model和View进行了分离,主要的程序逻辑在Presenter里实现。而且,Presenter与具体的View是没有直接关联的,而是通过定义好的接口进行交互,从而使得在变更View时候可以保持Presenter的不变,即重用!不仅如此,我们还可以编写测试用的View,模拟用户的各种操作,从而实现对Presenter的测试--而不需要使用自动化的测试工具。我们甚至可以在Model和View都没有完成时候就可以通过编写mock Object来测试Presenter的逻辑。
5、MVP的优势
模式与试图完全分离,我们可以修改视图而不影响模型
可以更高效地使用模型,因为所有的交互都发生在一个地方--Presenter内部
我们可以将一个Presenter用于多个视图,而不需要改变Presenter的逻辑。这个特性非常的有用,因为视图的变化总是比模型的变化频繁。
如果我们把逻辑放在Presenter中,那么我们就可以脱离用户界面来测试这些逻辑
四、MVVM模式
设计思想:MVVM模式中,一个ViewModel和一个View匹配,它没有MVP中的IView接口,而是完全的和View绑定,所有View中的修改变化,都会自动更新到ViewModel中,同时ViewModel的任何变化也会自动同步到View上显示
这种自动同步之所以能够实现的原因是ViewModel中的属性都实现了observable这样的接口,也就是说当使用属性的set方法,都会同时触发属性修改的事件,使绑定的UI自动刷新。
所以MVVM比MVP更升级一步,MVP中,V是接口IView,解决对于界面UI的耦合;而MVVM干脆直接使用ViewModel和UI无缝结合,ViewModel直接就能代表UI。但是MVVM做到这点是要依赖具体的平台和技术实现的,比如WPF和knockoutjs,这也就是为什么ViewModel不需要实现接口的原因,因为对于具体平台和技术的依赖,本质上使用MVVM模式就是不能替换UI的使用平台的
五、MVC、MVP和MVVM模式使用场景总结
由于在winform中无法像WPF一样,支持数据和界面的双向绑定以及事件的监控,所以,在winform中MVP是最佳选择。
WPF和html界面中使用Knockout,实现了observable,所以使用MVVM。
在web应用中,由于http是基于请求和响应方式协同工作的,无法一直保持连接状态,所以无法达到MVP中Presenter之间的消息传递和MVVM中的ViewModel和界面之间的绑定,所以MVC是最佳的选择。