Model View Presenter Pattern
- MVP is a variation of MVC, Loosely couple modules.
- It separates the concerns of an application’s data, presentation, and user input into specialized components.
- The view and the model don’t know of each other.
- There are normally four main classes used in the MVP pattern (3 classes and 1 interface)
- View (WinForm/ WebForm/XAML-file).
- Interface (describes the fields in view).
- Presenter (executes the views actions and communicates with the model).
- Model (database).
Variance of MVP
- 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.
Fig explains 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.
- 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 illustrates the logical view of the Passive View and Supervising Controller variants.
When to use what
- The decision to use Passive View or Supervising Controller lies primarily on the testability level that you want to achieve.
- 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.
- 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.
- 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.
- If we are going for automated testing like nUnit then Passive View is good, if we are going for manual testing than Supervisory Controller is good.
- Loose coupling – The presenter/controller are an intermediary between the UI code and the model. This allows the view and the model to evolve independently of each other.
- Clear separation of concerns/responsibility
- UI (Form or Page) – Responsible for rending UI elements
- Presenter/controller – Responsible for reacting to UI events and interacts with the model
- Model – Responsible for business behaviors and state management
- Test Driven – By isolating each major component (UI, Presenter/controller, and model) it is easier to write unit tests. This is especially true when using the MVP pattern which only interacts with the view using an interface.
- Code Reuse – By using a separation of concerns/responsible design approach you will increase code reuse. This is especially true when using a full blown domain model and keeping all the business/state management logic where it belongs.
- Hide Data Access – Using these patterns forces you to put the data access code where it belongs in a data access layer.
- Flexibility/Adaptable – By isolating most of your code into the presenter/controller and model components your code base is more adaptable to change. For example consider how much UI and data access technologies have changed over the years and the number of choices we have available today. A properly design solution using MVC or MVP can support multi UI and data access technologies at the same time.
- The biggest drawbacks are additional complexity and learning curve.
- While the patterns may not be appropriate for simple solutions; advance solutions can greatly benefit from using the pattern.