[自:http://hi.baidu.com/freezesoul/blog/item/cfb932adcef9c40b4b36d602.html] MVC和MVP的区别 MVC和MVP到底有什么区别呢? 从这幅图可以看到,我们可以看到在MVC里,View是可以直接访问Model的!从而,View里会包含Model信息,不可避免的还要包括一些业务逻辑。 在MVC模型里,更关注的Model的不变,而同时有多个对Model的不同显示,及View。 所以,在MVC模型里,Model不依赖于View,但是View是依赖于Model的。不仅如此,因为有一些业务逻辑在View里实现了,导致要更改View也是比较困难的,至少那些业务逻辑是无法重用的。 Visual Studio等快速开发工具,让我们很难把View和Controller分开,我们总是直接在View的事件响应函数里完成了Controller的代码。而在ASP.NET和XAML里,使用了一种叫做Co 把Controller和View混在一起,有什么问题? 1.难以测试。 必须手动点击,使用各种自动化的测试工具。 2.代码难以重用。 UI是很难重用,因为要求总是不同。所以,导致重复的代码四处都是,维护麻烦。 MVP是如何解决MVC的问题的? 在MVP里,Presenter完全把Model和View进行了分离,主要的程序逻辑在 Presenter里实现。而且,Presenter与具体的View是没有直接关联的,而是通过定义好的接口进行交互,从而使得在变更View时候可以 保持Presenter的不变,即重用! 不仅如此,我们还可以编写测试用的View,模拟用户的各种操作,从而实现对Presenter的测试--而不需要使用自动化的测试工具。 我们甚至可以在Model和View都没有完成时候,就可以通过编写Mock Object(即实现了Model和View的接口,但没有具体的内容的)来测试Presenter的逻辑。 在MVP里,应用程序的逻辑主要在Presenter来实现,其中的View是很薄的一层。 因此就有人提出了Presenter First的设计模式,就是根据User Story来首先设计和开发Presenter。在这个过程中,View是很简单的,能够把信息显示清楚就可以了。在后面,根据需要再随便更改View, 而对Presenter没有任何的影响了。 如果要实现的UI比较复杂,而且相关的显示逻辑还跟Model有关系,就可以在View和 Presenter之间放置一个Adapter。由这个 Adapter来访问Model和View,避免两者之间的关联。而同时,因为Adapter实现了View的接口,从而可以保证与Presenter之 间接口的不变。这样就可以保证View和Presenter之间接口的简洁,又不失去UI的灵活性。 在MVP模式里,View只应该有简单的Set/Get的方法,用户用户输入和设置界面显示的内容,除此就不应该有更多的内容,绝不容许直接直接访问Model--这就是与MVC很大的不同之处。 参考: MSDN的MVP介绍 一个不错的视频演示 Presenter First The Humble Dialog ----------------------------------------------- Alex在他的blog中对于mvc 与mvp 之间的比较: 【译文】: Model View Presenter vs Model View Controller 简介 在我工作中经常需要处理一些由于开发人员没能很清楚地理解MVC和MVP模式的区别的情况下使用它们而产生的问题。在这篇文章中我将会阐述一下我对两者之间区别的一些理解。 这两种模式中三个部分的一般理解 1、模型(Model)表示数据模型和业务逻辑(business logic)。模型并不总是DataSet,DataTable之类的东西,它代表着一类组件(components)或类(class),这些组件或类 可以向外部提供数据,同时也能从外部获取数据并将这些数据存储在某个地方。简单的理解,可以把模型想象成“外观类(facade class)”。【译注:这里的外观是指“外观模式”中所说的外观。外观的一般作用是为一个复杂的子系统提供高层次的简单易用的访问接口,可以参看下面的图来理解它的原理: MVC/P模式的核心是为了将模型从视图/控制器中分离出来,从而使得模型独立于它们,因此模型不包含对视图和控制的引用。 什么是MVC(Model View Presenter)模式? 1、为了使得视图接口可以与模型和控制器进行交互,控制器执行一些初始化事件 这一模式的有一下几个要点: “主动—MVC”模式,也是通常意义下的MVC模式 “被动—MVC”模式 MVP模式 与“被动—MVC模式”很接近,区别在于“视图并不使用模型”。在MVP模式中视图和模型是完全分离的,他们通过Presenter进行交互。Presenter与控制器非常相似,但是它们也有一些的区别: 1、Presenter处理视图发送过来的用户操作(在MVC中视图自己处理了这些操作) 2、它用更新过的数据去更新模型(在被动MVC中控制器只是通知视图去更新过的模型中去取新的数据,而主动MVC中模型通知视图去更新显示,控制器不需要做工作) 3、检查模型的更新(与被动MVC一样) 4、(与MVC的主要区别)从模型中取数据然后将它们发送到视图中 5、(与MVC的主要区别)将所做的更新告知视图 6、(与MVC的区别)用Presenter渲染视图 MVP的优势 1、模型与视图完全分离,我们可以修改视图而不影响模型 MVP的问题 由于对视图的渲染放在了Presenter中,所以视图和Persenter的交互会过于频繁。 还有一点你需要明白,如果Presenter过多地渲染了视图,往往会使得它与特定的视图的 联系过于紧密。一旦视图需要变更,那么 Presenter也需要变更了。比如说,原本用来呈现Html的Presenter现在也需要用于呈现Pdf了,那么视图很有可能也需要变更。 MVP模式根据 Module,View,Presenter之间的交互,可以分为Passive View(常规MVP)和Supervising Controller 2种。 Passive View模式:
大 家会发现MVP与MVC最大的一个区别就是“Model与View层之间倒底该不该通信(甚至双向通信)。我想这也是目前做这两方面研究的专家所互相争论 的战场。必定各有各的好处和因好处要付出的代价。起码在MVP模式下的Presenter要拥有“绝对权力”。如果没有它,MODEL与View就是两个 孤岛,尽管各有各的地盘(完全解耦),但不会给企业带来什么有用的价值。 所以我这里有一个比喻来形容MVP中的:
Presenter ----就是一个控制欲极强的女人,甚至就连“用什么姿势”,它都要管一管。 当 然日里万机操心多了就会让自己要做的事越来越多,最终它面临的就是该层代码日益庞杂,且书写起来不太方便,必定就连事件绑定这类鸡毛算皮的事都要归它管, 累不累呀。最终我们看到MVP中的View就真的代码轻闲了不少(国企职工嘛),难怪说View只要从相应的[IVIEW]接口下实现相应的属性和一些简 单方法就完事了,而最终调用[IVIEW]接口下的那个视图实例则完全交给了Presenter,这让我想到了MVC中可以支持“自定义模版引擎(最终由 MVC框架来控制使用系统还是自定义的模版引擎)”以及平时大家常挂在嘴边的换肤功能,想到这里多少还真有那么点意思了(精神层面上)。 当然在微软内部对MVP的理解也有所不同,如下面中所说的Supervising Controller模式和之前大家看到的PassiveView. Supervising Controller模式其实很接近于MVC的那张图了,只是又提供了Presenter与View之间的“双向通信”。这种做法也是有很多不同意见的,起码对那些支持“单向依赖”的开发者而言是“嗤之以鼻”的。 说到这里,虽然PassiveView模式有些霸道,但必定是让Model和View之间真正解耦,为开发者提供了最大的“控制成就感”,可以说想怎么控制视图就怎么控制,但因此所造成的问题就是代码书写量和实现复杂性等问题了。 |
|
来自: CoCO-Ebook > 《计算机IT》