MVC与MVP的区别
@in桂林理工大学
引用自博客园-冰冥寒流 侵删。
MVP与MVC有着一个重大的区别:在MVP中View并不直接使用Model,它们之间的通信是通过Presenter (MVC中的Controller)来进行的,所有的交互都发生在Presenter内部,而在MVC中View会直接从Model中读取数据而不是通过 Controller。
而MVP则是对MVC的进一步改造,以Andorid为例,实际上在MVC中很难区分Activity到底应该处于V还是C的角色,因为activity即包含了界面也包含了一部分逻辑处理。
MVP的出现就是为进一步分离业务逻辑和界面处理。在MVP中,M与V完全切断联系,由P进行总控。
当V接收到了操作,将相应的请求传递到P,由P进行业务处理以及与M进行交互,同时P又在恰当的时机对view进行更新(接口 / 回调方法 / 事件)
这样V只需要暴露出接口,V与P通过接口通讯,一方面能够将业务逻辑转移至P,一方面通过接口使得P可以适配多个V。
从这幅图可以看到,我们可以看到在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里,使用了一种叫做Code-Behind的技术,可以把View和Controller进行分离。这样,View就可以完全由UI设计工程师来完成,而Controller由程序员来完成,两者可以直接合成不需要像现在一样再由程序员做很多的工作。
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很大的不同之处。