Model-View-Presenter pattern has been around for quite some time. Though it seems that MVP is quite popular among .NET community, I don’t see much adoption in the Java camp. I’ve had quite a number of success on applying MVP to both Java and .NET projects, and have been a fan of this pattern since. On this blog post, I’m going to show you what MVP is, what it can offer, and why Java developers should pay attention to it.
Model-View-Presenter pattern
The key idea of MVP is the UI design that decouple the UI logic and UI representation. This will make the UI layer very thin and relieve it from any responsibilities as much as possible. Consider most of UI technologies come with the UI display and some logic attach to it (for example, binding event or data to Swing control). Having this coupling makes it difficult to automate the test for UI. Worse, if you decide to change the UI technology, you will have to rewrite this UI logic all over again.
MVP suggests the idea of separating UI logic to a separate class, the Presenter. The UI will have only small responsibilities of displaying data to the user and taking input. Two benefits of implementing this pattern are ease of UI testing and reuse of logic code on different presentation technology.
The Model
Model is where you store business logic, service, or data. It’s identical to the Model in Model-View-Controller architecture.
The View
The presentation layer of your application. In the context of MVP, the view should do nothing else but display data to and grab input from users.
The Presenter
You can think of presenter as an abstraction layer that glues the model and the view together. On the implementation level, this is done through the use of interface.
Model-View-Presenter with Swing
OK. Let’s see what the code looks like. Let’s say that I have a small book store application that does the following:
- Grab list of books from data source and display in a drop-down list.
- When user selects book from the drop down list, the detail of the book should be displayed on screen.
In normal Swing App, you’ll likely to see UI logic code stuck in actionPerformed method of an anonymous ActionListener class.
Traditional Swing application
However, with MVP, we try to remove UI logic from the view. So, the ActionListener will call presenter to perform this action.
Calling presenter on event
The presenter will join together the data from model and fetch it back to the view. As you can see, by wiring each component through interface, the view and the model are not aware of one another. You get a nice separation of concerns here.
Presenter class: handle the logic, tying view and model together
Model interface: data model provider must implement this interface
View interface that view class must implements
The implementation
Martin Fowler recently broke up MVP to two patterns: Supervising Controller and Passive View (since it’s Mr.Fowler who declared MVP, it’s legit for him to retire it?). The main difference between the two is the level of interaction between each component.
In Passive View pattern, each component has clear boundary. The view contains very few or minimum logic code. Both view and model rely heavily on presenter, this includes the view updating logic.
Nikola Malovic’s diagram demonstrates a very clean separation between each of the component
Implementing clean separation passive view involves a lot of code. Supervising Controller is very similar to Passive View but more relax. Supervising Controller allows some logic code to be in the view. It also allows the model to talk to the view directly for updating display data.
There are also other flavors of MVP out there. They have the same key ideas of UI decoupling, only the minor difference in how it’s done. I prefer the implementation that can give me the cleanest separation of concern between the view, the model, and the presenter. Neither the view nor the model should have any dependencies on the presenter.
Don’t restrict yourself to the diagram though. There are cases where it’s necessary and better to have the view and model communicate directly to one another. For instance, if your application does not have strong object model, displaying a form with 200 fields from 20 tables to screen can be a daunting task. In this case, you’ll have to create a new object entity class to store all these fields to maintain a clean separation. It’d be much easier and less code involved if the model can update the view directly.
Benefits of MVP
As I mention above, the most evident benefits of MVP are making the UI testable and independent from presentation technology. The topic of testing is tied to Test Driven Development which I will go into detail in future posts.
Extensibility
Recently a client had asked me to port a Java desktop application to the web. Although quite a chunk of time was required to refactor the old code, the porting process was remarkably smooth with MVP. Let’s look at the earlier bookstore example. Assume that we are asked to port this application to web version. For simplicity, let’s say that our web platform is simple Java servlets and JSP.
First, I create a servlet that control a index.jsp. I have this servlet implements IBookDetailView. At this point you may ask why the servlet, isn’t the servlet supposed to be acting as controller/presenter? We already have the presenter logic in place. The servlet here serves as the output channel to the JSP file.
Then inside the servlet’s init() method, I initialize the presenter and the model the same way I do in Swing version.
After implementing all view methods, the servlet is ready to pass down the data in the form of Java Bean to JSP file for display. We now go ahead and add code to the JSP file to display data.
And that’s all we have to do. As you can see, the beauty here is we accomplish this migration task with out having to change any logic or model code. MVP benefits heavily from the use of interface.
Using MVP design pattern can give you the extensibility for building user interface application. MVP in a sense, is a good practice of layering and applying dependency injection to your application.
You can download the source code for the example HERE
For more information on the MVP pattern
easy right? You can download Netbeans project for Typo 
