Building an application in an unplanned way suffers many problems, such as adding new features, making a huge effort as the architecture becomes rigid, maintaining the software (activities such as bug fixing) can turn into a nightmare, white box testing or unit testing the code becomes very difficult, and conflict and integration issues when many people work with the same or similar features. Generally, if no thought is given to refactoring as you go, the architecture may become a big ball of mud, and without planning, you may end up with a poor structure that might become difficult to change. To overcome these issues, we can employ many design patterns, such as MVC and MVP. GWT development goes very well with the MVP pattern as it allows loose coupling and separation of concerns.
The MVP approach divides the code into layers that solve the issues with code. MVP believes in separation of concerns and proposes the following logical layers:
- Model: A model encompasses business objects or data.
- View: A view contains all of the UI components that make up our application. This includes any tables, labels, buttons, textboxes, and so on. Views are responsible for the layout of the UI components and have no notion of the model. That is to say a view doesn't know that it is displaying a house or kangaroo; it simply knows that it has a label, two textboxes, and two buttons that are organized in a vertical or horizontal fashion.
Switching between views is tied to the history management within the presentation layer.
- Presenter: A presenter manages the views while updating the models when necessary. A presenter contains all of the logic for the application, including history management, view transition, and data synchronization via Remote Procedure Calls (RPCs) back to the server. In general, every view is driven by a presenter and it handles events that are sourced from the UI widgets within the view. RPC is an inter-process communication, which allows the GWT code to cause a Java process or procedure to execute in another address space.
The following figure represents the MVP components:
The presenter contains a view interface and a model. A concrete view is created and passed to the presenter; the presenter doesn't know about the concrete view, but it can access the methods of the view through the view interface. The view interface defines methods to render data, update the view, or access a DOM component of the view, but the interface should not return a low-level DOM component to the presenter. If a view contains a button, the interface should define a method to get hold of the button, but the method shouldn't return the button type; instead, it should return a high-level DOM component, such as clickable. The view doesn't handle the DOM events; the presenter implements the DOM event handling; for example, it will create a click event handler and set it to the button's handler list. That way, the view doesn't contain any logic. The presenter manages event handling and view transition. For example, consider a word processor application that has a view for listing all documents and has an edit button for editing a selected document. On the edit button, when you click on current (the list documents presenter), the presenter needs to change the view to the edit mode and open the document for editing. The list document presenter will fire an event so that another presenter can handle the edit operation. An edit document presenter will take care of the view. The presenter can update the model and send it to view for updating the view, such as a presenter making an asynchronous call to the server to get the updated stock price; on service callback, it will update the model with the latest data and call the view to update the new information.
The next section will demonstrate a GWT application and explain the MVP details.