美文网首页
通过分析Google的todo-mvp深度解析Android M

通过分析Google的todo-mvp深度解析Android M

作者: Ian888 | 来源:发表于2018-07-23 10:28 被阅读252次

    引言

    随着近些年MVP在Android上的火热,如今各种关于MVP的文章已经满天飞,由于各自的业务场景以及开发者自身的理解,MVP的使用方式是各不相同,各种复杂和混乱的文章导致Android初学者始终难以正确的在自己的项目中使用MVP,所以笔者写下了这篇文章。在学习MVP之前,我们首先要先了解其历史。

    MVC

    对于MVP (Model View Presenter)架构是从著名的MVC(Model View Controller)架构演变而来的。MVC概念最早源于1979年,其中Model表示模型,单独的对象或对象的结构,View是Model的可见表示,Controller为用户和系统之间的连接。而对于Android应用的开发中本身可视为一种MVC架构。通常在开发中将XML文件视为MVC中的View角色,而将Activity则视为MVC中的Controller角色。不过更多情况下在实际应用开发中Activity不能够完全充当Controller,而是Controller和View的合体。于是Activity既要负责视图的显示,又要负责对业务逻辑的处理。这样在Activity中代码达到上千行,甚至几千行都不足为其,同时这样的Activity也显得臃肿不堪。所以对于MVC架构并不很合适运用于Android的开发中。下面就来介绍一下MVP架构。

    MVP

    对于一个应用而言我们需要对它抽象出各个层面,而在MVP的UI架构模式中它将UI界面和数据进行隔离,所以我们的应用也就分为三个层次。

    View: 对于View层也是视图层,在View层中只负责对数据的展示,提供友好的界面与用户进行交互。在Android开发中通常将Activity或者Fragment作为View层。
    Model: 对于Model层也是数据层。它区别于MVC架构中的Model,在这里不仅仅只是数据模型。在MVP架构中Model它负责对数据的存取操作,例如对数据库的读写,网络的数据的请求等。
    Presenter:对于Presenter层他是连接View层与Model层的桥梁并对业务逻辑进行处理。在MVP架构中Model与View无法直接进行交互。所以在Presenter层它会从Model层获得所需要的数据,进行一些适当的处理后交由View层进行显示。这样通过Presenter将View与Model进行隔离,使得View和Model之间不存在耦合,同时也将业务逻辑从View中抽离。

    因此,MVP是一个非常好的解耦架构模式。下面我们来看一下google官方给出的这个todo-mvp的MVP架构示例。

    项目结构分析

    项目的目录结构

    它的目录结构是按模块的功能来划分。基本上每个模块下都有ActivityContractFragmentPresenter这四个主要的类。接下来我就选取其中addedittask这个模块进行分析和讲解。

    首先我先讲一下AddEditTaskContract这个类,Contract,中文意思就是契约,这里面规定了这个模块的所有业务逻辑。规定了View和Presenter的接口。MVP的V层和P层都用这个类规范了。让整个业务逻辑更加的清晰明确。下面贴出其代码。


    View

    由上图就可以看到,View 这个接口就是规定了UI显示的业务逻辑,这个模块的UI有什么逻辑就一目了然了。


    Presenter
    接下来就是上图的Presenter了,这个接口就是规定了这个模块的数据处理的业务逻辑。
    那么规定了这些接口是做什么的呢?当然接下来就要去实现它啦!
    AddEditTaskPresenter

    在这个AddEditTaskPresenter的类中,就实现了AddEditTaskContract.Presenter这个接口,注意上面的注释,其实已经给我们解释了这个类是做什么用的了。监听用户在UI上的动作,接收数据和更新请求的UI。实现了那个接口的话,类中就会重写那些接口定义好的方法。你只要把每个方法该实现的逻辑写在方法里就好了。

    到这里有的人可能会问,怎么没看到Model层呢?
    首先,我们复习一下,Model层是干什么的呢?Model层不仅仅是数据模型,还负责对数据的存取操作,例如对数据库的读写,网络的数据的请求等。那么在谷歌这个todo-mvp中把Model层放在data这个文件夹中。

    data文件夹目录
    这里就是用了谷歌自家的持久化数据层,Room Database。这个东西的用法我就不在这里详细介绍了。

    之后就是V层的使用了。在Fragment这个实际操作显示的类中,实现View的回调,控制View的显示。再在这里实例化presenter,调用presenter处理好的逻辑在相应的UI逻辑方法中使用。如下图


    Fragment

    而这里Activity这个类也只是起承载Fragment和传一些必要的值和对象给Fragment的作用而已。

    Activity
    最后在这里附上Google的todo-mvp的项目地址
    https://github.com/googlesamples/android-architecture/tree/todo-mvp/
    这就是基本而且逻辑比较清晰的Google推荐的MVP使用方式。当然还有更加进一步的架构模式,我会在以后的学习中再讲解。文章如有哪里写得不好,敬请各位大佬在下面指出。最后非常感谢大家的阅读!

    相关文章

      网友评论

          本文标题:通过分析Google的todo-mvp深度解析Android M

          本文链接:https://www.haomeiwen.com/subject/xtwfjftx.html