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 model, view, and presenter categories, which are explained in more details below:
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 Todor, 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);
}
};
...
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.
In Todor, the presenter class DocumentPresenter manages a single view of type ItemsView<Item>. This class implements two different interfaces:
-
Presenter, which captures the functionality used by the app controller. It contains a singlego()method. -
ItemsView.Presenter<Item>, which captures the functionality used by the view. It contains multiple methods for adding, updating, and deleting objects of the parameter type T, in this caseItem.
To achieve simpler class responsibilities (aka single responsibility principle), the presenter functionality is further partitioned into several classes. The DocumentPresenter class is the main class in this group which drives the application logic and is also responsible for saving and loading model classes to and from the backend via its DocumentService instance. Another notable class is the DocumentData class, which manages a single document and its items on the client, including saving and loading to and from HTML5 local storage.
See:
The AppController class handles logic that is not specific to any presenter and instead resides at the application layer. This component contains the history management and view transition logic. It fulfills its responsibilities by creating, displaying, and invoking appropriately presenters and views.
See: