This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies.
The forms in a smart client application frequently contain various controls, handle user events, and contain logic to alter the controls in response to these events. Writing this code in the form class makes the class complex and difficult to test. In addition, it is difficult to share code between forms that require the same behavior.
Separate the responsibilities for the visual display and the event handling behavior into different classes. A view class manages the controls on the form, and it forwards events to a presenter class. The presenter contains the logic to respond to the events, and in turn, manipulates the state of the view. The presenter class uses the model (frequently, this is application state that is represented by business entitles) to determine how to respond to the events.
This solution separates the responsibilities and also allows you to test the behavior without using the user interface.
Figure 1 illustrates the logical view of the pattern.
MVP pattern logical view
The model holds the business data, such as business entities. The model is unaware of the presenter that changes its state. The view holds a reference to its presenter and delegates to the presenter the handling of all user events (no business logic is implemented in the view). The presenter does not reference the class that implements the view; instead, it references an interface for the view (IView). With this, you can easily substitute one view implementation with another for the same presenter. One application of this feature is to test your presenter with a view implementation that does not have a user interface.
The recommended organization of the code is to put a view, the view interface, and the presenter classes in a separate project folder, as illustrated in Figure 2.
MVP pattern implementation view
For an example of this pattern, see the AppraisalDetail project folder in the AppraiserWorkbenchModule project. The folder contains the IAppraisalDetailView interface, AppraisalDetailView class, and AppraisalDetailViewPresenter class.
The AppraisalDetailView class does the following:
- It implements the IAppraisalDetailView interface.
- It has an associated AppraisalDetailViewPresenter object. The CreateNew attribute on the Presenter property causes ObjectBuilder to create and inject a new instance of an AppraisalDetailViewPresenter object after the construction of the AppraisalDetailView object.
- It sets the View property of the presenter to itself.
- It contains the method ShowAppraisal. The presenter uses this method to instruct the view to display the details for an appraisal.
- It calls the presenter for click events; the presenter contains the logic for the responses to the events.
The AppraisalDetailViewPresenter class contains the logic for responding to the user interaction with the view. It also contains the event handler WorkingAppraisalSelectedHandler. This method responds to an event raised by another view to indicate that the user selected an appraisal. When the presenter receives this event, it calls the ShowAppraisal method of the AppraisalDetailView view to display details for the selected appraisal.