在Andoid开发中使用MVP模式来解耦，增加可测试性

by Jeff Angelini posted on 7/20/2011 2:35:00 PM

将应用程序UI的表现从Ui的逻辑中分离是一个好的想法。这种分离减少了代码耦合，代码更加干净， 甚至可以有更多的单元测试覆盖率。Android在Activity类中绑定了UI 和 UI 逻辑 class。这种绑定，使测试变得困难甚至不可能，因为依赖的代码不能被模拟。 然而，简单的 MVP 模式可以帮助在 Android 应用程序解耦 UI 和 UI 逻辑。

MVP模式全称Model-View-Presenter， 它分离 UI的数据(Model)，UI (View)的显示，UI的逻辑 (Presenter)之间的关系。对于 Android来说，View就是Activity，它是用来处理收集用户输入，更新界面的显示； Presenter是用来处理Model和View之间通讯的类； Model用来保存和查询数据，以及数据相关的业务逻辑。接口可以用来解耦这三个组件。一个简单的典型的View用来展示是怎么实现MVP的。

First, our CustomerActivity (the View) will have textboxes for the Customer’s ID, first name, and last name:

private EditText mFirstNameEditText, mLastNameEditText, mIdEditText;

The user will load a customer using the mIdEditText and a Load Button. Likewise, the user will save a customer using a Save Button:

private Button mSaveButton, LoadButton;

We must now create a CustomerPresenter with the following methods:

public CustomerPresenter(ICustomerView View)
public void saveCustomer (String firstName, String lastName)
public void loadCustomer (int id)

We then can wire it all up in the CustomerActivity’s onCreate method:

mCustomerPresenter = new CustomerPresenter(this); mSaveButton.setOnClickListener(this);
mLoadButton.setOnClickListener(this);

The CustomerActivity class must now implement the interfaces OnClickListener (for handling the Button’s OnClickListeners) and ICustomerView (for the CustomerPresenter constructor). The OnClickListener defines the method void onClick(View v), and our method will look like the following:

switch (v.getId()) {
case R.id.saveButton:
mCustomerPresenter.saveCustomer(mFirstNameEditText.getText().toString(),
mLastNameEditText.getText().toString());
break;
case R.id.loadButton:
mCustomerPresenter.loadCustomer(Integer.parseInt(mIdEditText.getText().toString()));
break;

The previous two code sections show that when the Save Button is clicked, the saveCustomer method of our presenter will be called with the Customer’s first name and last name information; and when the Load Button is clicked, the loadCustomer method of our presenter will be called.

We haven’t defined ICustomerView, so we’ll do that now. When loading the customer, the CustomerPresenter will need to be able to update the CustomerActivity’s last name, first name, and ID EditTexts, so ICustomerView will look like the following:

void setLastName (String lastName);
void setFirstName (String firstName);
void setId(int id);

The CustomerActivity’s implementation of these methods will set the corresponding EditText to the value of the parameter.

The CustomerPresenter, then, will look like the following:

private ICustomerView mCustomerView;
private ICustomerModel mCustomerModel;
public CustomerPresenter(ICustomerView view) {
mCustomerView = view;
mCustomerMode = new CustomerModel();
}
@Override
public void saveCustomer(String firstName, String lastName) {
mCustomerModel.setFirstName(firstName);
mCustomerModel.setLastName(lastName);
}
@Override
public void loadCustomer(int id) {
(mCustomerModel.load(id)) {
mCustomerView.setId(mCustomerModel.getId());
mCustomerView.setFirstName(mCustomerModel.getFirstName());
mCustomerView.setLastName(mCustomerModel.getLastName());
}
}

The implementation of the CustomerModel isn’t important for our purposes; we just need to know that it is being saved to a repository of some sort. Furthermore, the CustomerModel is currently tightly-coupled to the CustomerPresenter, which can be remedied by injecting it as a dependency.

The CustomerPresenter allows the CustomerActivity class to be as simple as possible. The activity now only gathers user input for the presenter and provides simple UI update methods for the presenter. Since the CustomerView and CustomerModel implement interfaces and can be injected into the CustomerPresenter, it is not dependent on them. Therefore, they can by mocked, which allows the CustomerPresenter logic to be unit tested.

After Note: This MVP pattern is sometimes referred to as Passive View, since the view only passes along data, either to or from its presenter. The MVP pattern can also be implemented such that the View knows of the model. The view responds to state changes in the model for simple UI updates, while the presenter handles more complex UI logic. This more complex pattern is sometimes referred to as Supervising Controller.

In Android, this can be accomplished by the Model using Java’s Observable class and the View implementing the Observer interface; when something changes in the Model, it can call the Observable’s notifyObservers method. It can also be implemented with Android’s Handler class; when something changes in the Model, it can send a message to a handler that the View injects into it.