MVPforAndroid:如何来设计Presenter层(译)

前言

• 最近在研究MVP如何设计presenter层,正好看到antonioleiva的博客,加之最近也在练习英语,所以记录下.
• 原文链接:http://antonioleiva.com/mvp-android

正文

MVP (Model View Presenter) 模式是众所周知MVC (Model View Controller)模式的衍生,MVP 模式在一段时间内在开发Android应用方面变得很重要.并且越来越多的人开始谈论他,但是很少有可靠的和结构化的信息.这就是为什么我想要用这个博客去鼓励讨论并且用我们所学知识去用最好的方式在我们的项目中运用它.

• 什么是MVP?
  MVP模式允许把presenter层从逻辑中分离出来,因此所有关于接口如何工作将从我们把它展示在屏幕上分离出来.MVP模式将要完美的达到:同样的逻辑可能有完全不同的和可交换的视图.

• 为什么使用MVP?
  在Android开发中,我们有一个问题呈现在一个事实面前,那就是android中的activities与接口和数据访问机制紧密相连.我们可以发现一个极端的案例,例如CursorAdapter,它混合了adapters,然而adapters是视图的一部分并且带有Cursor,因此有些东西应当被降级到数据访问层的深处.

  为了是一个应用更加容易的扩展和可维持的,我们应当去定义一个很好的分离层.如果说明天我们做什么呢?取而代之的从数据库重去除相同的数据,我们需要从webservice操纵它吗?我们不得不将要去重做我们的整个View吗.

  MVP模式让views藏数据源中独立出来,我们把一个应用至少分为三种不同的层.他能让我们独立的测试他们.在MVP模式下,我们能够把更多的逻辑处理从activity中抽离出来,因此我们能够测试它在没有使用任何仪器的情况下测试.

• 在Android中如何去实现MVP
  好了,这就是一切开始变得更加分散的地方.这里有很多不同的MVP并且每一个都可以根据自己的需要和更加舒适的方式去调整MVP模式.模式的多样化主要依赖于我们代表的presenter的职责.

  是否View要去响应一个可用或者不可用的progressbar,或者他应当在presenter层中处理吗?并且是谁决定了哪一个行为应当在actionbar中显现?这就是艰难决定开始的地方.我将会向你展示我平时怎么工作的,但是我想要这篇文章成为一个严格的知道方针在如何去应用MVP上的一个讨论的地方.因为要知道这里没有一个标准的方式去实现它.

• presenter层:
  presenter层就扮演的类似一个中间人的职责在view和model之间.它从model层中去检索数据并且返回它表现在view上.但是不像典型的MVC,它同样决定你和view交互时会发生什么,

• view层
  View,通常在一个activity中实现(或者是一个fragment,一个view..这取决于app是怎么安排的),同样和presenter关联起来.Presenter 将被一个依赖注射器例如:Dagger完美的提供,但是为了以防你不会使用像这些的东西,他将会负责去创建Presenter对象.View层每次只需要做一件事,那就是回调presenter里面的一个方法–一个接口(类似一个按钮点击的clicklistener)

• model层:
  在一个好的app应用里面有一个好的层级结构,这个model只是作为一个去domain层或者业务逻辑的入口.如果我们使用Uncle Bob clean architecture,这个model层可能会成为一个实现一个使用用例的关联.但是这是另外一个我想在今后的文章中讨论的一个主题.在现在,它能足够去显现作为一个数据的提供者我们想要展示在view中.

• 案例:
  这是一个优点冗长的解释,我创建了一个MVP的案例https://github.com/antoniolg/androidmvp,由一个登陆界面证明从model层获取的数据和允许进入home界面带有一个列表的子项.这篇文章并没有解释任何一个代码,因为它太简单了,但是如果你明白你发现它很难去理解,我或许或创建另一篇文章去解释它.
• 结论:
  在Android中去分离接口和逻辑并不容易.但是Model-View-Presenter层让阻止我们的activities结束降低成为一个关联了成百上千行代码的关联class变得容易.在一个大型的APP应用去组织你的代码很好是必要的.否则,它变得很难保养和拓展.

项目源码

• 当然最后就是原作者提供的代码案例,因为是老外写的没有注释,因此我加了一些我的理解在里面,如果有错误的地方,希望矫正.
• 点击下载