MVP 设计模式理解,实战理解MVP
来源:互联网 发布:油田开发数据 编辑:程序博客网 时间:2024/05/21 01:49
1、什么是MVP
MVP,全称 Model-View-Presenter。它是从 MVC中演变过来的,它的基本思想是相通的;在MVP中,View更加专注于处理数据的可视化以及用户交互,让Model专注于数据的处理,而Presenter则,提供 View 与 Model 之间数据的纽带,用于交互与数据传输;如下面这张图:
可以看到,在View 与 Model 之间我们是通过 Presenter,也就是 interface 来实现view 与数据的交互的,大大降低耦合,方便进行单元测试。至于与 MVC 的异同,自行google吧,这里就不细说了。
其实,自己在写代码的时候,心中有个概念就好了,view 就是UI,model就是数据处理,而persenter 则是他们的纽带。心中有个轮廓,写起来就不那么费劲了。
2、使用 MVP 的 优缺点
我们在使用一种设计模式的时候,首先都会问,为什么要用这种模式,能给我们带来哪些方便?用了这种模式,它的缺点会不会给我的工程造成影响?
首先,优点上,我们上面已经阐述了;
- 减低耦合,实现了 Model 与View 的真正分离,修改 View 而不影响 Model
- 模块职责分明,层次分明,便于维护,多人开发首选。
- Presenter 可以服用,一个 Presenter可以用于多个 View,不用去改 Presenter
- 利于单元测试。模块分明,那么我们编写单元测试就变得很方便了,而不用特别是特别搭平台,人工模拟用户操作等等耗时耗力的事情。
缺点:
对于小工程,额外多出来的代码量,和额外的代码复杂度,毕竟那么多 interface ,但对于它的有点来说,完全可以接受。
3、实战
我们就简单一个数据保存的例子好了。至于数据库的保存,采用郭霖大神的 LitePal,连接如下:
http://blog.csdn.net/column/details/android-database-pro.html
先上效果:
非常简单,就是获取 EditText的数据,保存在数据库,然后重新把它读取出来,结构图如下:
首先,从上面的效果图来看,我们需要 name 和 password 这两个字符串,我们需要新建一个 User 类,由于要用到 LitePal ,所以让它继承 DataSupport;如果你使用自己写的,那就不用继承啥了。:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
Model:
然后,我们思考一下,从View 传过来的数据name和password,我们是要保存起来的,所以,我们先在 model,编写数据保存和读取的方法:
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
它的具体实现方法如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
方法很简单,就保存一下数据和读数据。什么?数据库保存这样就行了?是的,所以赶紧去学习 LitePal 吧。
View:
View这里,我们是专注于UI的显示和用户交互的,上面我们通过名字的方式从数据库中读取,然后把它显示出来。所以,我们需要添加 name 和password 的显示方法,当然还有出错的方法:
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
然后让mainactivity 继承这个接口重写该方法:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
Presenter :
好了,现在我们的 View 和 Model 都是单独开了的,所以,我们需要一个纽带,把view 和model 连接起来;那就是我们的 Presenter 了:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
ok,其他都写好了,那么接下来,只要写onclick事件就可以了:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
这样,我们就实现了一个简单的 MVP demo了。
疑问:
- 这样,你可能会有疑问?一个简单的demo被你写得这么复杂,还说这个设计模式有多好?
- 这么简单的,接口都那么多,那稍微复杂点的,那接口不是直接上天和太阳肩并肩了吗?
可能很多人有这样的疑问,是的,在一些小工程,或者一个项目只有一两个人开发的时候,你可以酌情考虑要不要使用这种模式,而使用这种模式,就考验你对接口的理解和使用了。
而稍微复杂点的,和多人开发的,我建议是使用这种模式的,当然没有完美的框架,适合自己的才是最重要的,反正我用的挺嗨的,有点搞逼格的感觉,笔者就试过一个稍微复杂的项目,多人开发,最后搞得很混乱,牵一发而动全一身;
- MVP 设计模式理解,实战理解MVP
- MVP 设计模式理解,实战理解MVP
- 理解MVP设计模式
- 理解MVC,MVP和MVVM设计模式
- 理解MVC,MVP和MVVM设计模式
- Android MVP设计模式的理解
- 理解MVC,MVP和MVVM设计模式
- 理解MVC,MVP和MVVM设计模式
- 理解MVC,MVP和MVVM设计模式
- 理解MVC,MVP和MVVM设计模式
- 理解MVC,MVP和MVVM设计模式
- mvp设计模式的个人理解
- 理解MVC,MVP和MVVM设计模式
- 理解MVC,MVP和MVVM设计模式
- 理解MVC,MVP和MVVM设计模式
- mvp模式理解
- MVP模式简单理解
- MVP模式的理解
- Swift
- androidStudio打包后百度地图出不来的问题
- PUTTY中永久更改字体大小
- 史上最全greendao源码解析
- el 表达式
- MVP 设计模式理解,实战理解MVP
- 算法-剑指offer-二叉搜索树的后序遍历序列
- 配置ssm的错误整合
- mysql 严格模式 Strict Mode
- 在centos阿里云服务器上配置apache+php+mysql环境
- Ajax 简介
- strucs2拦截器有什么作用
- Python小练习
- photoshop制作gif去掉杂色