MVP Architecture
The Model-View-Presenter (MVP) architecture is outlined in Large scale application development and MVP. At the heart of the MVP design pattern is the separation of application logic (presenter) from the UI presentation (view). It is recommended when developing GWT apps for the following reasons:
- Decouples development in a way that allows multiple developers to work simultaneously
- Allows writing lightweight and fast JRE unit tests which don't require a browser
- Allows creating different views for different devices that share the same presenter logic
The class diagram below shows the main classes and interfaces of the Todor application and their separation into the following categories, which are explained in more details below:
- Model
- View
- Presenter
- AppController
The domain model classes represent entities from our problem domain. In Todor, these are documents and items. Domain model classes are lightweight POJOs which are shared between the client and the server. See Domain Model Classes for more information.
See:
View classes contains the UI components that make up our application's user interface, including tables, labels, buttons, text boxes, etc. Views are also responsible for the layout of the UI components. Switching between views is tied to the history management within the presentation layer.
Views have no notion, or only have a very abstract notion, of the model. In our example, the view interface ItemsView<T> and its implementation ItemsViewImpl<T> are parameterized with the model class T as they are intended to display a list of items of type T. All concrete operations on items however are carried out via the presenter, which should implement the ItemsView.Presenter<T> interface.
As an example, in ItemsViewImpl<T> items are displayed in a CellTable<T>. The item text is displyed in a column which is created with the following code:
private Column<T, String> createTextColumn() {
Column<T, String> col = new Column<T, String>(new EditTextCell()) {
@Override
public String getValue(T t) {
return presenter.getText(t);
}
};
col.setFieldUpdater(new FieldUpdater<T, String>() {
@Override
public void update(int index, T t, String value) {
presenter.updateText(t, value);
dataProvider.refresh();
}
});
return col;
}Note that in the above code, getting or updating the item text is forwarded to the presenter, which is of course the only way it could be done since T is the parameter of the class and ItemsViewImpl<T> does not know its operations.
See:
Presenter classes contain all of the application logic, including history management, view transition and RPC client / server communication. For every view there is usually a presenter to drive the view and handle events that are sourced from the UI widgets within the view.
See: