mvp模式

一、MVP概述 MVP，全称 Model-View-Presenter，即模型-视图-层现器。 提到MVP，就必须要先介绍一下它的前辈MVC，因为MVP正是基于MVC的基础发展而来的。两个之间的关系也是源远流长。 MVC，全称Model-View-Controller，即模型-视图-控制器。 View：对应于布局文件 Model：业务逻辑和实体模型 Controllor：对应于Activity 但是View对应于布局文件，其实能做的事情特别少，实际上关于该布局文件中的数据绑定的操作，事件处理的代码都在Activity中，造成了Activity既像View又像Controller，使得Activity变得臃肿。 而当将架构改为MVP以后，Presenter的出现，将Actvity视为View层，Presenter负责完成View层与Model层的交互。现在是这样的： View 对应于Activity，负责View的绘制以及与用户交互 Model 依然是业务逻辑和实体模型 Presenter 负责完成View于Model间的交互 下面两幅图通过数据与视图之间的交互清楚地展示了这种变化： MVC模式下实际上就是Activty与Model之间交互，View完全独立出来了。 MVP模式通过Presenter实现数据和视图之间的交互，简化了Activity的职责

相信大家对MVC，MVP和MVVM都不陌生，作为三个最耳熟能详的Android框架，它们的应用可以是非常广泛的，但是对于一些新手来说，可能对于区分它们三个都有困难，更别说在实际的项目中应用了，有些时候想用MVP的，代码写着写着就变成了MVC，久而久之就对它们三个的选择产生了恐惧感，如果你也是这样的人群，那么这篇文章可能会对你有很大的帮助，希望大家看完都会有收获吧！ 文章重点： (1)了解并区分MVC，MVP，MVVM。 (2)知道这三种模式在Android中如何使用。 (3)走出data binding的误区。 (4)了解MVP+data binding的开发模式。 本篇文章的demo我将会上传到 我的github上 。 水之积也不厚,则其负大舟也无力 正如庄子在逍遥游中说的，如果水不够深，那就没有能够担负大船的力量 。所以在真正开始涉及具体的代码之前，我们要先对MVC，MVP和MVVM做一个初步的了解。如果各位同学对此已经有所了解了，可以选择性跳过这一节。 MVC MVC，Model View Controller，是软件架构中最常见的一种框架，简单来说就是通过controller的控制去操作model层的数据，并且返回给view层展示，具体见下图 当用户出发事件的时候，view层会发送指令到controller层，接着controller去通知model层更新数据

MVC，MVP，MVVM基本原理 模式与框架，其诞生就是为了解决日益复杂的事务处理 当同一问题不断出现，人们就会总结细分出相应的问题解决办法 当需求变得庞大的时候，就会出现细分，在细分的过程中就会出现不同的解决办法 在 界面、数据、事件、业务 这些元素的细分下，出现了最早的模式MVC MVC 即 Model-View-Controller Model-View-Controller 模型 视图 控制器 MVC、MVP、MVVM、Code Behind 等等都源自于职能分化和规划的思想与目的，MVC只是他们的开始 MVC流程一般是这样的： View层触发事件 Controller处理业务 之后触发数据更新、 不知道谁更新的 Model回到了View View更新数据 MVC在你出现数据变化的时候需要同时维护三个对象和三个交互，这使得事务复杂化了，人们在解决这一问题的时候诞生了新的优化模式MVP MVP Model-View-Presenter模式 MVP 的模式 切断了 View 和 Model 的联系，使得View只和Presenter联系（Controller）交互，减少了在变化中需要维护的对象的数量 MVP定义了Presenter和View之间的接口，让一些可以根据已有的接口协议去各自分别独立开发，以此去解决界面需求变化频繁的问题 计算机依赖摩尔定律用数量的增长来解决问题