MVP：如何组织Presentation层

by Antonio Leiva | Apr 15, 2014 | Blog, Development | 108 comments

MVP (Model View Presenter) pattern is a derivative from the well known MVC (Model View Controller), which for a while now is gaining importance in the development of Android applications.

MVP模式是著名MVC模式的衍生物，现在这在Android开发中获取的极大的发展。

There are more and more people talking about it, but yet very few reliable and structured information.

越来越多的人来讨论它，但是鲜有可靠和结构化的信息。

That is why I wanted to use this blog to encourage the discussion and bring all our knowledge to apply it in the best possible way to our projects.

这也是我带来这篇博客，来促进讨论，把我们所有的知识尽最大可能应用到我们的项目之中。
What is MVP?

The MVP pattern allows separate the presentation layer from the logic, so that everything about how the interface works is separated from how we represent it on screen.

MVP模式使得presentation层从逻辑中分离出来，所以所有界面的工作从如何在屏幕上展示中分离出来。

Ideally the MVP pattern would achieve that same logic might have completely different and interchangeable views.

理想情况下,MVP 模式将会实现相同逻辑下可能完全不同的View。

First thing to clarify is that MVP is not an architectural pattern, it’s only responsible for the presentation layer .

首先我们需要澄清的是MVP不是一个结构化的模式，他只是对presentation层负责而已。

In any case it is always better to use it for your architecture that not using it at all.

在任何情况下，使用它来完善你的项目架构总比完全不使用要好的。
Why use MVP?

In Android we have a problem arising from the fact that Android activities are closely coupled to both interface and data access mechanisms.

我们在现实Android开发中有一个问题逐渐显现出来，Android的activity与用户界面和数据访问机制关系非常密切。

We can find extreme examples such as CursorAdapter, which mix adapters, which are part of the view, with cursors, something that should be relegated to the depths of data access layer .

我们可以发现极端的例子，如CursorAdapter的，它搭配适配器，这是该视图的一部分，使用游标，这东西应该被降级到数据访问层的深处。

For an application to be easily extensible and maintainable we need to define well separated layers. What do we do tomorrow if, instead of retrieving the same data from a database, we need to do it from a web service? We would have to redo our entire view .

为使一个应用能够简单的扩展和维持，我们需要去定义好分离的层。如果我们明天需要从网络服务上面获取数据，而不是从数据库中。我们将不得不重新处理整个view。

MVP makes views independent from our data source. We divide the application into at least three different layers, which let us test them independently. With MVP we are able to take most of logic out from the activities so that we can test it without using instrumentation tests.

MVP使View从我们的数据源上独立，我们将应用分为三个不同的层次，这使得我们可以单独的测试他们。使用MVP我们可以将大多数逻辑从activity中抽取出来
How to implement MVP for Android

Well, this is where it all starts to become more diffuse. There are many variations of MVP and everyone can adjust the pattern idea to ​​their needs and the way they feel more comfortable.

那么，这里所有开始变得更加分散。MVP有很多的变化，每个人都可以根据他们的需要来调整这个模式，这种方式会更加舒服

The pattern varies depending basically on the amount of responsibilities that we delegate to the presenter.

这种模式的变化基本取决于我们委托给Presenter的责任量。

Is the view responsible to enable or disable a progress bar, or should it be done by the presenter?

View应该控制进度条的显示和不显示，还是Presenter应该做这个工作呢？

And who decides which actions should be shown in the Action Bar? That’s where the tough decisions begin .

谁又应该控制哪一项action在ActionBar中进行显示呢？这也是比较难讨论的观点

I will show how I usually work, but I want this article to be more a place for discussion that strict guidelines on how to apply MVP, because up to know there is no “standard” way to implement it .

我将会给你展示我通常是怎么操作的，但是我想通过这篇文章通过不止一个地方来讨论应用MVP的严格大纲。这由于MVP不是一个标准的实现方式。
The presenter

The presenter is responsible to act as the middle man between view and model. It retrieves data from the model and returns it formatted to the view. But unlike the typical MVC, it also decides what happens when you interact with the view.

Presenter在View和Model之间充当中间人的角色。它从Model中检索数据，然后返回格式化View。但是与典型的MVC不同。他也取决于你与View之间进行了什么样的交互。
The View

The view, usually implemented by an Activity (it may be a Fragment, a View… depending on how the app is structured), will contain a reference to the presenter.

View通常由Activity来实现（或者是Fragment，View）取决于App如何组织结构。View将会包含于Presenter之间的关联。

Presenter will be ideally provided by a dependency injector such as Dagger, but in case you don’t use something like this, it will be responsible for creating the presenter object.

Presenter在理想情况会由注入类库提供，比如Dagger，但如果你不这样使用，这就需要创建一个Presenter对象。

The only thing that the view will do is calling a method from the presenter every time there is an interface action (a button click for example).

View唯一需要做的事情是只要一有界面交互（比如按钮点击事件）就从Presenter中调用方法
The model

In an application with a good layered architecture, this model would only be the gateway to the domain layer or business logic.

具有良好组织架构的应用。这样的模型将会成为通往主导层和业务逻辑层的唯一通道。

If we were using the Uncle Bob clean architecture , the model would probably be an interactor that implements a use case. But this is another topic that I’d like to discuss in future articles. For now, it is enough to see it as the provider of the data we want to display in the view.

如果我们使用Uncle Bob clean architecture.该Model层很可能会成为实现一个使用实例的交互器。但是这也是我在今后的文章中将要讨论的另一个话题。到现在，足够将它视为我们想要展现在View上的数据提供者
An example

As it is a bit lengthy to explain , I created an MVP example on Github consisting of a login screen that validates the data and allows access to a home with a list of items that are retrieved from the model. This article does not explain any code because it is quite simple, but if you see that you find it difficult to understand I may create another article explaining it in detail.

上面说的话有点多，我在GitHub 上写了一个demo, an MVP example on Github 有登陆页面，验证数据，然后访问从Model中拉取一系列的数据的Home页面。这篇文章不提供任何的代码，因为它太简单了。但是如果你觉得有点困难，我会写另一篇文章来细致的阐述它。

Go to MVP example on Github
Conclusion

Separating interface from logic in Android is not easy, but the Model-View-Presenter pattern makes a little easier to prevent our activities end up degrading into very coupled classes consisting on hundreds or even thousands of lines. In large applications it is essential to organize our code well. If not, it becomes impossible to maintain and extend.

Android中从逻辑里面讲用户界面分离出来并不是那么容易，但是MVP设计模式能有效避免activity最终分解为带有成千上百行代码的高耦合的类。在大型的App中组织好代码是非常必要的，如果不这样做，很难进行维护和扩展。+