-
MVP
(MVP 模式)
编辑
mvp的全称为Model-View-Presenter,Model提供数据,View负责显示,Controller/Presenter负责逻辑的处理。MVP与MVC有着一个重大的区别:在MVP中View并不直接使用Model,它们之间的通讯是经过Presenter (MVC中的Controller)来进行的,全部的交互都发生在Presenter内部,而在MVC中View会直接从Model中读取数据而不是经过 Controller。
-
中文名
-
MVP
-
外文名
-
Model-View-Presenter
-
通讯方式
-
Presenter
-
位 置
-
在Presenter内部
MVP 是从经典的模式MVC演变而来,它们的基本思想有相通的地方:Controller/Presenter负责逻辑的处理,Model提供数据,View负责显示。做为一种新的模式,MVP与MVC有着一个重大的区别:在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也是比较困难的,至少那些业务逻辑是没法重用的。
[1]
在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很大的不一样之处。
[1]
一、模型与视图彻底分离,咱们能够修改视图而不影响模型
二、能够更高效地使用模型,由于全部的交互都发生在一个地方——Presenter内部
三、咱们能够将一个Presenter用于多个视图,而不须要改变Presenter的逻辑。这个特性很是的有用,由于视图的变化老是比模型的变化频繁。
四、若是咱们把逻辑放在Presenter中,那么咱们就能够脱离用户接口来测试这些逻辑(单元测试)
[1]
因为对视图的渲染放在了Presenter中,因此视图和Presenter的交互会过于频繁。还有一点须要明白,若是Presenter过多地渲染了视图,每每会使得它与特定的视图的联系过于紧密。一旦视图须要变动,那么Presenter也须要变动了。好比说,本来用来呈现Html的Presenter如今也须要用于呈现Pdf了,那么视图颇有可能也须要变动。