MVP那些事儿(1) 用场景说话

目录

MVP那些事儿(1)……用场景说话

MVP那些事儿(2)……MVC架构初探

MVP那些事儿(3)……在Android中使用MVC（上）

MVP那些事儿(4)……在Android中使用MVC（下）

MVP那些事儿(5)……中介者模式与MVP的关系

MVP那些事儿(6)……MVC变身为MVP

MVP那些事儿(7)……Repository设计分析

引言

随着这几年移动互联网的快速发展，移动互联网技术也获得了推进，辅助架构设计型的框架和思想层出不穷，从井喷的2015年到如今，开发者们愈来愈离不开这些高性能、高效率的工具，而制造这些工具的公司或我的，也被推到神坛，受猿们的膜拜。与此同时，Google在今年的io大会上发布了本身的官方框架Architecture Components【译】，能够说是至关的应景了。时不我待，了解架构的知识，而且灵活的应用是咱们程序员将来必不可少的技能，这系列文章是介绍MVP架构的，但愿能对阅读此文的朋友们带来些收获。

一、如何实现一个MVP框架的基本原则，以及MVP的使用场景，是我想写这篇文章的初衷，同时也是对我本身学习的知识作一个整体的融合。

二、为了不一上来生硬的开场，我先以一个简单的开发例子做为引子，以初学者的角度去看待问题，同时也能兼顾到初学者，到后面咱们会一步步提示。因此你也能够选择直接跳转到。。。。

三、由于讲架构，可能是场景描述，因此代码量比较少，习惯于经过代码理解的同窗，我尽可能多些并反复描述。

场景

假设实现一个商品的列表展现功能，咱们首先须要一个用户界面，包含一些控件来供用户操做，好比列表展现。咱们大多数状况下使用一个Fragment做为控件的载体，在Fragment中直接调用网络请求的工具并等待回调方法被执行后去刷新UI去展现数据，因此对于这个需求的代码量并非不少。如今需求增长了，要加入下拉刷新和上拉加载更多，通常是监听这两个事件，在相应的回调中处理数据，没几行代码，依旧写在Fragment中，而需求又一次增长了，要加入排序，紧接着咱们处理排序逻辑，代码依旧写在Fragment中，接着又增长需求了，加入详情页的跳转，可能跳转前要处理些业务逻辑，接着又要增长需求了，列表视图能够从宫格式转变为瀑布式，须要改变控件的样式，……接着新需求又来了，可编辑的列表项，能够删除和修改列表项，同时数据要同步到服务器，需求又来了，编辑列表项须要动画功能……直到这个时候咱们回头再看看咱们的Fragment，这个时候咱们可能没法容忍Fragment里混乱复杂的逻辑了。

从功能性需求的角度来讲，功能完整、软件正常运行，这是没有问题的，但回过头来我看了一下代码觉的并非那么“没问题”，在不使用架构的状况下，咱们无感知的将逻辑代码业务以及视图代码都堆积到了Activity当中，这样的角色能够说是至关的臃肿的，同时很是不利于将来的扩展，因而非功能性的需求须要知足：Activity优化与扩展性。

咱们再梳理一下这个场景的需求列表：

一、列表展现

二、列表支持下拉刷新，上拉加载更多

三、列表要能够排序，可能会有n个条件

四、列表的item点击跳转到详情页面

五、列表展现须要多样化，瀑布流变宫格

六、列表可编辑，也许包括CURD，同时要同步服务器

七、编辑列表时，加上动画效果

下一章节，咱们首先使用加入架构的方式来处理上面的需求，其中会介绍Model的定义，Controller的职责，以及它们如何经过控制反转来进行解耦，若是你对MVC有了足够的了解，能够直接跳转到MVP的章节。