Model View Presenter: The Basics

Basics

The Model-View-Presenter design pattern is a modern pattern to seperate the view from the underlying model. MVP is a derivative of the model–view–controller (MVC) software pattern, also used mostly for building user interfaces.

There exists many MVP Variations, but basically the Model-View-Controller (MVP) looks like this:

• The model is an interface defining the data to be displayed or otherwise acted upon in the user interface.
• The view is an interface that displays data (the model) and routes user commands (events) to the presenter to act upon that data. The view usually (excepted MVP Passive View variant) has a reference to its presenter.
• The presenter acts upon the model and the view. It retrieves data from repositories (the model), and formats it for display in the view and vice versa. You can say: The presenter is the "middle-man" (played by the controller in MVC) and has references to both, model and view. Normally the presenter observes the model to receive model updates. So when an model update has happend, the presenter will update the view by invoking the corresponding view method.

Example

So lets have a look on a concrete scenario:

Example: Assume we have a small customer relationship management application and the user of our application is currently editing customer detail information. So the EditCustomerView is displayed on screen. With this scenarion in mind lets have a closer look to the figure displayed above.

1. The user wants to save the changes. Therefore he clicks on the save button. This will lead the view to invoke the presenters method presenter.updateCustomer(String newName, String newAddress, ...);
2. The presenter is now going to manipulate the concrete Customer object, the model, by calling customer.setName(newName), ... etc.
3. The changes were stored successful, so the model lets the presenter know, that the changes were stored successful.
4. The presenter calls view.showSuccessful() to display a successful message on screen.

Use Interfaces for Views

You should define Java Interfaces for every view in your application. This has the big advantage that your presenter knows only the Interface instead of the concrete view implementation. This means, that you can replace the concrete view implementation with any other implementation, for example a test mock view. You see the MVP pattern allows you to easily write unit test by replacing the concrete view with a mock view.

The code for the customer relationship management example could be look like this:

interface EditView {
     public void showSuccessfulMessage();
}

class EditViewImpl implements EditView { ... }

class EditPresenter{
     private EditView view;       // The view
     private Customer customer;   // The model

     public EditPresenter(EditView view, Customer customer){
          this.view = view;
          this.customer = customer;
      }
}

Because we have defined the EditView and the EditPresenter uses this interface instead of the concrete implementation (EditViewImpl) we simply can define a mock view for test cases

class EditViewMock implements EditView { ... }

and pass an instance of EditViewMock to the EditPresenter.

As you see, every View-Presenter combinations consists at least of 2 classes and 1 interface

• View-Interface
• View implementation (class)
• Presenter (class)

---

Read previous: It all starts with the EventBus

Read next: Model-View-Presenter: Using MVP-Lite