Android架构模式二：MVP

原文地址：https://upday.github.io/blog/model-view-presenter/

Android架构模式：MVP

我们的开发人员是时候考虑如何在Android应用中应用良好的架构模式了。为此Google推出了Android Architecture Blueprints项目，在这个项目中，Erik Hellman与我基于MVP与RxJava创建了一些示例。现在来看看我们是如何应用的，以及这种方案的优点与缺点。

MVP模式

以下是各个组件的角色：

• Model-数据层，负责管理业务逻辑并维护网络和数据库接口。
• View-UI层，显示数据并通知Presenter用户行为。
• Presenter-从Model中查询数据，处理UI逻辑，管理View状态，决定显示内容，并响应来自View的用户输入。

由于View与Presenter密切合作，它们需要互相引用。为了让Presenter可以使用JUnit作单元测试，View会被抽象为一个接口。Presenter与其相应View之间的关系定义在Contract接口中，使得代码更易读，两者之间的联系更易于理解。

在Android Architecture Blueprints中的MVP与RxJava

项目中的示例是一个“待办事项”应用。它允许用户创建、阅读、更新和删除“待办事项”储备，以及过虑任务列表。RxJava用于隔离主线程与执行异步操作。

Model

Model与远程和本地数据源协作，以获取和保存数据。这里正是处理业务逻辑的地方。例如，当请求任务列表时，Model会试着先在本地数据源查询。如果没用，它就请求网络，并将响应的数据保存在本地数据源中，最后返回列表。
任务查询是在RxJava的帮助下来完成的：

public Observable> getTasks(){
    ...
}

Model通过构造方法持有本地和远程数据源，这使得Model完全独立于Android类，从而便于做单元测试。例如，为了测试getTasks从本地请求数据，我们实现以下测试方法：

@Mock
private TasksDataSource mTasksRemoteDataSource;
@Mock
private TasksDataSource mTasksLocalDataSource;
...

@Test
public void getTasks_requestsAllTasksFromLocalDataSource() {
    // Given that the local data source has data available
    setTasksAvailable(mTasksLocalDataSource, TASKS);
    // And the remote data source does not have any data available
    setTasksNotAvailable(mTasksRemoteDataSource);

    // When tasks are requested from the tasks repository
    TestSubscriber> testSubscriber = new TestSubscriber<>();
    mTasksRepository.getTasks().subscribe(testSubscriber);

    // Then tasks are loaded from the local data source
    verify(mTasksLocalDataSource).getTasks();
    testSubscriber.assertValue(TASKS);
}

View

View与Presenter一起工作，显示数据，并通知Presenter关于用户的行为。在MVP中，Activity、Fragment与自定义控件都可作为View。这里我们使用Fragment。
所有View都实现了一个可以关联Presenter的BaseView接口。

public interface BaseView {
    void setPresenter(T presenter);
}

View会在onResume中调用Presenter的subscribe方法来告知Presenter它已经准备好做更新操作。而在onPause中调用presenter.unsubscribe()来告知Presenter它不再接收更新操作。如果View的实现是一个自定义控件，那么subscribe与unsubscribe方法会在onAttachedToWindow与onDetachedFromWindow中调用。用户行为，如点击按钮，将触发Presenter中相应的方法，这决定了下一步流程。
我们使用Espresso来测试View。例如，要在屏幕上显示活动任务和已完成任务列表。单元测试首先会创建一些任务放在TaskRepository中，然后启动StatisticsActivity来检测是否正确显示：

@Before
public void setup() {
    // Given some tasks
    TasksRepository.destroyInstance();
    TasksRepository repository = Injection.provideTasksRepository(
            InstrumentationRegistry.getContext());
    repository.saveTask(new Task("Title1", "", false));
    repository.saveTask(new Task("Title2", "", true));

    // Lazily start the Activity from the ActivityTestRule
    Intent startIntent = new Intent();
    mStatisticsActivityTestRule.launchActivity(startIntent);
}

@Test
public void Tasks_ShowsNonEmptyMessage() throws Exception {
    // Check that the active and completed tasks text is displayed
    Context context = InstrumentationRegistry.getTargetContext();
    String expectedActiveTaskText = context
            .getString(R.string.statistics_active_tasks);
    onView(withText(containsString(expectedActiveTaskText)))
            .check(matches(isDisplayed()));
    String expectedCompletedTaskText = context
            .getString(R.string.statistics_completed_tasks);
    onView(withText(containsString(expectedCompletedTaskText)))
            .check(matches(isDisplayed()));
}

Presenter

Presenter与其相应的View由Activity创建；View与TaskRepository（即Model）的引用由构造方法传入；在构造方法中，Presenter将调用View的setPresenter方法。以上过程可以由依赖注入框架简化，允许向Presenter注入相应的View，以降低类之间的耦合度。这个方案可以在另一个由Dagger实现的实现中找到。
所有Presenter都实现了BasePresetner接口。

public interface BasePresenter {
    void subscribe();
    void unsubscribe();
}

当subscribe方法调用时，Presenter向Model请求数据，然后将UI逻辑应用于接收到的数据，最后传递给View。例如，在StatisticsPresenter中，所有任务都是向TaskRepository查询得到的，查询结果会用于计算活动任务和已完成任务的数量。这些数量将用作View方法showStatistics(int numberOfActiveTasks, int numberOfCompletedTasks)的参数。
一个检测showStatistics是否调用了正确值的单元测试是很好实现的。我们将模拟TaskRepository和StatisticsContract.View，然后将模拟对象作为StatisticsPresenter构造方法的参数。以下是测试实现：

@Test
public void loadNonEmptyTasksFromRepository_CallViewToDisplay() {
    // Given an initialized StatisticsPresenter with
    // 1 active and 2 completed tasks
    setTasksAvailable(TASKS);

    // When loading of Tasks is requested
    mStatisticsPresenter.subscribe();

    // Then the correct data is passed on to the view
    verify(mStatisticsView).showStatistics(1, 2);
}

unsubscribe的作用是清除Presenter中的观察者，防止内存泄露。
除了subscribe与unsubscribe，每个Presenter也会依据View中的用户行为暴露一些其它方法。例如，AddEditTaskPresenter会添加如createTask这样的方法，来响应用户点击任务创建按钮的行为。这保证所有用户行为（以及随后的UI逻辑）都通过Presenter，从而可以进行单元测试。

MVP模式的缺点

MVP带来了很好的关注分离方案。虽然这确实是一个优点，但是在开发小应用时，这似乎是个不小的开销。为了减少接口数量，一些开发人员删除了Contract，以及Presenter的接口。
当把UI逻辑移到Presenter中时，一个缺陷出现在了：Presenter变成了一个拥有数千行代码的全知类。为了解决这个问题，应该更多地分割代码并记住仅创建单一职责且可作单元测试的类。

结语

MVC模式有两个主要缺点：第一，View同时持有Controller与Model的引用；第二，没有限制UI逻辑在单一的类中，而是由Controller与Model共享。MVP模式通过对View与Model解耦，并且只创建一个类处理所有与View呈现相关的事情，即Presenter（一个容易进行单元测试的类），从而解决了以上问题。

如果我们想要一个事件驱动的架构呢？View在哪里响应变化？请继续关注Android Architecture Blueprints示例中的下一个模式，以了解如何实现这一点。届时请阅读upday应用中关于MVVM模式的实现。

Written with StackEdit.