架构篇-MVC演化MVP

浅谈下当前项目架构思路，早起是基于MVC模式的，打算基于MVP试试，先简单介绍下。

MVC (Model-View-Controller)：

M是指逻辑模型，V是指视图层，C则是控制器。一个逻辑模型可以对应多种视图模块，比如一批统计数据你可以分别用柱状图、饼图来表示。一种视图模型可以在不同视图页共用。使用MVC的目的是将M和V的实现逻辑代码与视图层分离，从而使同一个程序可以使用不同的表现形式，而C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。

android的官方建议应用程序的开发采用mvc模式。

图中实线表示方法调用，虚线表示事件响应

1) 视图层（View）：一般采用XML文件进行界面的描述，使用的时候可以非常方便的引入复用。同样也可以直接代码生产视图，一般需要动态加载的布局或者自定义视图使用。当然，你也可以想到在Android中也可以使用JavaScript+HTML等的方式作为View层，当然这里需要进行Java和JavaScript之间的通信，Android提供了它们之间非常方便的通信实现。    

2) 控制层（Controller）：Android的控制层的重任通常落在了众多的Acitvity的肩上，这句话也就暗含了不要在Acitivity中写过多业务代码，要通过Activity交割Model业务逻辑层处理，所以这一层就是拿到模型层的数据，交互判断一下，调用展示到视图层上，事件响应处理，建立视图层与模型层的关联。

3) 模型层（Model）：对业务逻辑处理、数据库、对网络等的操作都应该在Model里面处理，具体开发中我们有许多业务实体处理类和第三方工具模型，最终使项目多人开发过程中，层次分明，耦合性低。

开发新需求时：视图层-->控制层-->模型层

在开发的过程中拿到高保真图的时候，按这个思路，一层一层实现处理，并且预估各层的用时，以进行项目用时预估。第一步先确认视图展示需要的布局，控件，完成页面视图，第二步交互判断（输入框必须为数字，密码，不为空等等。。。），第三步，业务逻辑处理实现对应模型，接口调试，本地数据存储更新等。

需求变更：模型层-->控制层-->视图层

需求不可能一撮而就，需求变更应该说是是我们做的产品向更好的方向改变，也是家常便饭，特意也提出来说一下，但是处理思路和开发新需求缺是相反的。当需求出现变化的时候，产品已经做了一部分雏形，不易大幅更改，并且各层都有成型，修改的时候，先分析业务逻辑的变化，对模型层做出对应的修改，接着是交互操作过程的梳理，最后确认视图层展示。

基于这个理解，将Activity当做核心，做为控制层（Controller），对视图层VIEW区域，封装视图实体，来更新数据模型，其实，思路和listview与adapter一样，activity在业务实体获取数据，刷新到view实体上。

MVP（Model - View - Presenter）

首先说下，MVP应该是MVC的延伸版，最终 Presenter取代了Controller的角色， 而当将架构改为MVP以后，Presenter的出现，将Actvity视为View层，Presenter负责完成View层与Model层的交互， 减少了Activity的职责，简化了Activity中的代码，将复杂的逻辑代码提取到了Presenter中进行处理。与之对应的好处就是，耦合度更低，更方便的进行测试，复用，管理。

• View 对应于Activity，负责View的绘制以及与用户交互
• Model 依然是业务逻辑和实体模型
• Presenter 负责完成View于Model间的交互   

其实最明显的区别就是，MVC中是允许Model和View进行交互的，而MVP中很明显，Model与View之间的交互由Presenter完成。还有一点就是Presenter与View之间的交互是通过接口的。

将一下，具体改善过程中的一些应用点，一个Activity对于一个presenter，而一个presenter可以对于多个Activity复用，view层的Activity与presenter层响应交互，Activity里只封装关于视图刷新的view实体，公共ui方法，以接口的形式提供给Presenter层调用，刷新页面。或者View层，交互发起的事件，调用presenter层的方法去model层调用业务实体处理后，一路接口回调，来返回响应结果，最终刷新VIew层。Activity只处理交互判断与视图刷新，Presentercer层连接View与model，将控制连接代码从Activity中分离出来，view层与model直接关系，必须经过presenter来连接。MVC环形循环调度，到MVP链式响应的一个改善，是个人认为最大的简化。