MVP

 

The approach we’ll use to model this application is MVP, Model/View/Presenter.

Here, the Presenter sits between the Model and the View. The View knows nothing of the Presenter and the View knows nothing of the Model. This is actually a variation of MVP called Passive View (see Martin Fowler’s Passive View write-up for more details http://martinfowler.com/eaaDev/PassiveScreen.html).

For the purposes of this discussion, we’ll refer to all the functionality related to the left-hand Contact List as the ‘Contact List UI Component’ and all the functionality related to the right-hand Contact Detail as the ‘Contact Detail UI Component’. Each UI Component will have an M, a V, and a P. Within each of those UI components, we’ll explore the responsibilities and distinctions between their respective Models, Views, and Presenters. For the Contact List UI Component, we can think of it mapping to MVP in this way:

ContactListModel

The Model is a strongly-typed representation of the data to display in the UI Component. For both UI components, this is based on a Contact, a fairly simply bean that holds the attributes of a Contact.

ContactListView

In the MVP approach, the core responsibility of the View is to represent the user interface. User interfaces are very loosely typed. In the HTML world for our Contact List, this ultimately ends up being a String on a page, something like <a>Jim</a>, an element in the DOM, and an onClick event that can call out to do stuff.

ContactListPresenter

The ContactListModel is a strongly-typed data holder and the ContactListView is just the primitive aspects of the user interface. This leaves the rest of the responsibilities of the UI component to the ContactListPresenter:

· Translating the Model to the View for display. For example, taking the first name String from a Contact object and passing that String in to the ContactListView.

· Translating the View to the Model for updates. If for example, the user could update the user’s name directly from the Contact List, the Presenter would take the String entered and put that in to the Contact object’s first name attribute.

· Translate actions the user takes on their interface in to strongly-typed events that can be emitted out of the Presenter. What does it mean to be a strongly-typed event? Our text-based user interface can do little more than tell us that “Jim”, the String, was clicked. However, all our Java business logic really wants to deal with is meaningful objects: in this case, the Contact Model. The Presenter’s responsibility will be to convert the View action indicating “Jim, the String, was clicked” in to a Presenter event indicating that “Jim, the Contact, was clicked”.

· The ContactListPresenter will not only emit events such as “the user clicked on Jim”. It will also be listening for events emitted by other presenters in case those events need to change the View of the Contact List UI Component. For example, if the ContactDetailPresenter could emit an event that a Contact was changed, the ContactListPresenter would listen for that event so it could send appropriate parts of the updated Contact in to the ContactListView.

We’ll look at code samples later about how all these responsibilities can be fulfilled in GWT.