MVP模式在Alldroid中应用研究.docVIP

MVP模式在Alldroid中应用研究 　　摘要：传统的MVC模式在Android的应用开发中存在诸多不足，主要表现在Android应用开发的关键类Activity会充当Controller和View的合体，既要负责业务逻辑，又要负责显示，造成Activity的职责过多，耦合度高。MVP模式是MVC模式演进而来，引入了Presenter彻底分离Model和View层，在解决Activity臃肿的问题同时，还有助于后期的测试与维护。本文分析MVC对于Android开发的不足，并探索MVP模式在Android开发中的可行性，以及优劣势，最后实现MVP模式在Android开发中的应用。 　　关键词：Android；MVP；模式 　　引言 　　GUI（Graphical User Interface）应用程序出现之后，应用程序也变得更加复杂，为了管理这种复杂性，基于职责分离的思想而孕育而出了MVC模式。在Android开发过程中，同样会采用MVC模式的思想，将访问和数据的表现分离。一般的处理是将进行界面描述的XML文件作为视图层（View），使用的时候可以非常方便的引入，同时便于后期界面的修改。将Activity等类作为控制层（Controller），来控制View层和Model层的通信，以此来达到分离视图显示和业务逻辑层，其中与业务相关的数据结构类作为模型层（Model），用来处理数据库的操作、网络请求等操作。但其实Activity并不是一个标准的MVC模式中的Controller，它的首要职责是加载应用的布局和初始界面，以及接受并处理来自用户的操作请求，并做出响应。随着界面及其逻辑的复杂度不断提升，Activity类的职责不断增加，以致变得庞大臃肿。不仅如此，在Android中，允许View和其它线程共存于Activity内，造成的问题是Activity中同时存在业务逻辑和UI逻辑，成为包罗万象的“上帝类”，这大大增加了应用后期的测试和维护成本。为了使Android应用开发简单，各层次职责清晰，增加可读性和复用性，减少后期的测试、维护成本，本文在Android开发应用中引人MVP模式。 　　1 MVP模式 　　MVP从MVC演变而来，通过表示器将视图与模型巧妙地分开。在该模式中，视图通常由表示器初始化，它呈现用户界面（UI）并接受用户所发出命令，但不对用户的输入作任何逻辑处理，而仅仅是将用户输入转发给表示器。通常每一个视图对应一个表示器，但是也可能一个拥有较复杂业务逻辑的视图会对应多个表示器，每个表示器完成该视图的一部分业务处理工作，降低了单个表示器的复杂程度，一个表示器也能被多个有着相同业务需求的视图复用，增加单个表示器的复用度。表示器包含大多数表示逻辑，用以处理视图，与模型交互以获取或更新数据等。模型描述了系统的处理逻辑，模型对于表示器和视图一无所知。 　　1.1MVP模式的引入 　　在Android开发应用中，MVP的结构划分：视图（View）负责绘制uI元素、与用户交互，在Android开发中对应于Activity相关的类；模型（Model）类似于数据加工处理厂，负责对数据的获取，数据的解析，数据的存储，数据的分发，数据的增删改查等操作；表示器（Presenter）作为View与Model交互的中间纽带，处于MVP的中间层，表示器会把视图递交的命令进行一定的校验等操作，然后交给模型层处理，模型层处理完数据之后，会通知表示器，表示器主动去获取数据处理的结果递交给视图层显示。因此表示器有封装业务，更新UI界面和持有线程等功能。各模块数据的交互见图1。 　　从上图可以看出，MVP的分层结构特别类似于网络的七层协议，每层只知道自己依赖层的细节。层与层之间的耦合性低，模块的复用性高，可维护性高，降低了测试的复杂度。 　　按照View和Presenter的交互方式和View本身的职责，可以将MVP划分为PV（PassiveView）和SoC（Superviding Controller）。其中PV中的View是被动的，由Presenter来推送和获取数据，这也是普遍的用法，本文研究的MVP模式也属此种模式。MVP模式的变种Passive View中各模块的依赖关系如图2所示。 　　在被动视图（passive View）模式中，表示器通过接口与视图交互。采用这种方案可以使表示器自身成为一个可重用性和可测试性均很高的类。首先，表示逻辑独立于所使用的UI技术，其次，针对某一接口为表示器编码，该表示器可以与实现该接口的任何对象交互，而实现该接口的可能是Activity对象、Fragment对象等，这意味着只要视图接口不变，视图的任何更新都不会影响到表示器。这就能使单个表示器只专注于它自己的职责，使得表示器层结构简单，逻