OVERVIEW
Model –View-Presenter ( MVP ) Pattern is one of the popular design pattern for creating the enterprise application, introduced by Martin Fowler, this pattern leverage many functionalities of loose coupling modules.
The Intention is separation between its business logic to user interface design, and for the developer will just keen to think to the particular business logic to drive the application, the MVP Pattern also enhance the fully functionality of module testing, which mean you could use mock object to test your every module and class or every single wire in your MVP application.
There are many kind implementation of MVP Pattern, one of the best and become the easiest way to implement the MVP Pattern is using the MVP framework from the Microsoft Pattern and Practise team. In this case I’ll try to explain of using the MVP Bundle package from them which is become the embedded skeleton as a library tools in your visual studio.
Analysis Surgery
Actually there are two variants functionality and also the benefit that we could get from this bundle, which are Passive View and Supervising Controller.
Problem
A page in a Web application contains controls to display application domain data. A user can modify the data and submit the changes. The page retrieves the domain data, handles user events, alters other controls on the page in response to the events, and submits the changed domain data. Writing this code in the Web page (the code-behind class) makes the class complex, difficult to maintain, and hard to test. In addition, it is difficult to share code between Web pages that require the same behavior.
Forces
You want to maximize the code that can be tested with automation. (Views are hard to test.) You want the share code between pages that require the same behavior. You want to separate business logic from UI logic to make it easier to understand and maintain.
Solution
Separate the responsibilities for the visual display and the event handling behavior into different classes, the view and the presenter. The view class (the Web page) manages the controls on the page, and it forwards events to a presenter class. The presenter contains the logic to respond to the events, update the model (business logic and data of the application) and, in turn, manipulate the state of the view.
To facilitate testing the presenter, make the presenter have a reference to the view interface instead of to the view concrete implementation. By doing this, you can easily replace the real view with a mock implementation to run tests.
View Updates
When the model is updated, the view has to be updated to reflect the changes. View updates can be handled in several ways. The Model-View-Presenter variants Passive View and Supervising Controller specify different approaches to implement view updates.
In Passive View, the presenter updates the view to reflect changes in the model. The interaction with the model is handled exclusively by the presenter; the view is not aware of changes in the model.
In Supervising Controller, the view interacts directly with the model to perform simple data-binding that can be defined declaratively, without presenter intervention. The presenter updates the model; it manipulates the state of the view only in cases where complex UI logic that cannot be specified declaratively is required. Examples of complex UI logic might include changing the color of a control or dynamically hiding/showing controls. Figure 1 illustrates the logical view of the Passive View and Supervising Controller variants.
Figure 1
Passive View
In figure 1, explain about interaction by model is handled exclusively by the presenter and then the view is updated exclusively by the presenter which using the view interface.
The decision to use Passive View or Supervising Controller lies primarily on the testability level that you want to achieve for your application. If testability is a primary concern in your application, Passive View might be more suitable because you can test all the UI logic by testing the presenter. On the other hand,
Figure 2
Supervising Controller
if you prefer code simplicity over full testability, Supervising Controller might be a better option because you do not have to write code in the presenter to update the view for simple changes ( as you can see at the figure 2 above ). When choosing between Passive View and Supervising Controller, consider the following:
- Both variants allow you to increase the testability of your presentation logic.
- Passive View usually provides a larger testing surface than Supervising Controller because all the view update logic is placed in the presenter.
- Supervising Controller typically requires less code than Passive View because the presenter does not collaborate in simple view updates.
Note:
In the View-Presenter pattern, the presenter exclusively handles the interaction with the model and updates the view; the view is not directly bound to the model. Thus, this approach is in line with the Passive View variant described in this topic.
Interaction with the Model
You can implement the interaction with the model in several ways. For example, you can implement the Observer pattern and have the presenter listen to events of the model and update the view as required. Another approach is to use an application controller to update the model.
Liabilities
There are more solution elements to manage.
You need a way to create and connect views and presenters.
The model is not aware of the presenter. Therefore, if the model is changed by any component other than the presenter, the presenter must be notified. Typically, notification is implemented with events.
Entries (RSS)