简称:MVP 全称:Model-View-Presenter ;MVP 是从经典的模式MVC演变而来,它们的基本思想有相通的地方:Controller/Presenter负责逻辑的处理,Model提供数据,View负责显示。
中文名
MVP模式
外文名
MVP mode演 变
MVC
方 式
直接Model中读取数据
逻 辑
Presenter
MVP模式概述
编辑
MVP从MVC演变而来,通过表示器将视图与模型巧妙地分开。在该模式中,视图通常由表示器初始化,它呈现用户界面(UI)并接受用户所发出命令,但不对用户的输入作任何逻辑处理,而仅仅是将用户输入转发给表示器。通常每一个视图对应一个表示器,但是也可能一个拥有较复杂业务逻辑的视图会对应多个表示器,每个表示器完成该视图的一部分业务处理工作,降低了单个表示器的复杂程度,一个表示器也能被多个有着相同业务需求的视图复用,增加单个表示器的复用度。表示器包含大多数表示逻辑,用以处理视图,与模型交互以获取或更新数据等。模型描述了系统的处理逻辑,模型对于表示器和视图一无所知。[1]
MVP的全称为Model-View-Presenter,Model提供数据,View负责显示,Controller/Presenter负责逻辑的处理。MVP与MVC有着一个重大的区别:在MVP中View并不直接使用Model,它们之间的通信是通过Presenter(MVC中的Controller)来进行的,所有的交互都发生在Presenter内部,而在MVC中View会直接从Model中读取数据而不是通过Controller。[2]
MVP模式优势
编辑
MVP模式下表示层的优势体现在下面三个方面:
1、View与Model完全隔离。
得益于此,Model和View之间具有良好的松耦合设计,这意味着,如果Model或View中的一方发生变化,只要交互接口不变,另一方就没必要对上述变化做出改变。这使得Model层的业务逻辑具有很好的灵活性和可重用性。
2、Presenter与View的具体实现技术无关。
也就是说,采用诸如Windows表单,WPF,Web表单等用户界面构建技术中的任意一种来实现View层,都无需改变系统的其他部分。甚至为了使B/S,C/S部署架构能够被同时支持,应用程序可以用同一个Model层适配多种技术构建的View层。
3、可以进行View的模拟测试。
过去,由于View和Model之间的紧耦合,在Model和View同时开发完成之前对其中一方进行测试是不可能的。出于同样的原因,对View或Model进行单元测试很困难。现在,MVP模式解决了所有的问题。在MVP模式中,View和Model之间没有直接依赖,开发者能够借助模拟对象注入测试两者中的任一方。[3]
MVP模式MVC & MVP
编辑
MVP是从经典的模式MVC演变而来,它们的基本思想有相通的地方:Controller/Presenter负责逻辑的处理,
MVP模式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也是比较困难的,至少那些业务逻辑是无法重用的。 [2]
MVP模式问题改进方式
编辑
在MVP里,Presenter完全把Model和View进行了分离,主要的程序逻辑在Presenter里实现。而且,Presenter与具体的View是没有直接关联的,而是通过定义好的接口进行交互,从而使得在变更View时候可以保持Presenter的不变,即重用。不仅如此,我们还可以编写测试用的View,模拟用户的各种操作,从而实现对Presenter的测试--而不需要使用自动化的测试工具。我们甚至可以在Model和View都没有完成时候,就可以通过编写MockObject(即实现了Model和View的接口,但没有具体的内容的)来测试Presenter的逻辑。在MVP里,应用程序的逻辑主要在Presenter里实现,其中的View是很薄的一层。因此就有人提出了PresenterFirst的设计模式,就是根据UserStory来首先设计和开发Presenter。在这个过程中,View是很简单的,能够把信息显示清楚就可以了。在后面,根据需要再随便更改View,而对Presenter没有任何的影响了。如果要实现的UI比较复杂,而且相关的显示逻辑还跟Model有关系,就可以在View和Presenter之间放置一个Adapter。由这个Adapter来访问Model和View,避免两者之间的关联。而同时,因为Adapter实现了View的接口,从而可以保证与Presenter之间接口的不变。这样就可以保证View和Presenter之间接口的简洁,又不失去UI的灵活性。在MVP模式里,View只应该有简单的Set/Get的方法,用户输入和设置界面显示的内容,除此就不应该有更多的内容,绝不容许直接访问Model--这就是与MVC很大的不同之处。
MVP模式优点
编辑
MVP与MVC的主要区别是View与Model不直接交互,而是通过与Presenter来完成交互,这样可以修改视图而不影响模型,达到解耦的目的,实现了Model和View真正的完全分离。视图的变化总是比较频繁,将业务逻辑抽取出来,放在表示器中实现,使模块职责划分明显,层次清晰,一个表示器能复用于多个视图,而不需要更改表示器的逻辑(当然是在该视图的改动不影响业务逻辑的前提下),这增加了程序的复用性。数据的处理由模型层完成,隐藏了数据,在数据显示时,表示器可以对数据进行访问控制,提高数据的安全性。以前的Android开发是难以进行单元测试的,但是随着项目变得复杂,测试时保证应用质量的关键,MVP模式中,表示器对视图是通过接口进行的,可以利用测试驱动,模拟出视图对象,实现视图相对于表示器的接口,就可以对表示层进行不依赖于UI环境的单元测试了,这大大降低了Android应用开发中的业务逻辑测试难度和复杂度。MVP模式的引入,视图层完全不依赖与模型层,相当于将视图从特定的业务场景中脱离出来,做到了对业务完全不可知的状态,因此可以将视图层组件化,提供一系列接口供表示层操作,这样就可以做出高度可复用的视图组件了。[1]
MVP模式缺点
编辑
MVP的明显缺点是增加了代码的复杂度,特别是针对小型Android应用的开发,会使程序冗余。Presenter中除了应用逻辑以外,还有大量的View->Model,Model->View的手动同步逻辑,会导致Presenter臃肿,维护困难。视图的渲染过程也会放在Presenter中,造成视图与Presenter交互过于频繁,如果某特定视图的渲染很多,就会造成Presenter与该视图联系过于紧密,一旦该视图需要变更,那么Presenter也需要变更了,不能如预期的那样降低耦合度和增加复用性。[1]
参考资料
1.
曾露.MVP模式在Android中的应用研究[J].软件,2016,37(6):75-78.
2.
张正龙,陈永政.浅谈MVP设计模式[J].科学咨询,2014,(28):71-71.
3.
朱滕威.基于Android的开发模式研究[J].环球市场,2018,(15):388.