Model View Presenter(MVP) Pattern

Model

The model is a direct reference to your domain logic—the business logic layer so to speak. This provides access to the back-end data (from the database) and implements additional business logic on it. As when we do authentication for a user, we need to manage encryption and decryption of the password. Such things will be managed by model.

View

The view is made up of the .aspx and .cs files of your webpage. These files are responsible for defining the physical items that a user interacts with in your website. They are also responsible for receiving the various events that a user raises while navigating through your site. The handled events should be immediately passed

to the presenter rather than being handled in the view. Doing this ensures that the presenter has all the logic and the application remains testable. It is the responsibility of the presenter to decide how to handle each event. The view is required to pass itself (by reference) to the presenter giving the presenter total control over the view.

Presenter

The presenter is a separate class file. There should be one presenter file per webpage.The presenter is ultimately responsible for indirectly handling events fired by the view and directly controlling what the view displays. It is the only part of the presentation layer that can communicate with the domain objects (or the model). Tests can be wrapped around the presenter object. While this is not a full test of the UI, it is a full test of the logic that the UI interacts with.

How it works

To quickly describe how this works from a programmatic point of view, let's think about loading a list of people. The view would contain something like a GridView or some other form of Repeater. The steps would be like that:

Model View Presenter Pattern

1. On loading, the view would instantiate its presenter. It then passes a reference of itself to that presenter by calling an init method in the presenter.
2. This passes the control of the view to the presenter. The presenter is now responsible for initializing the page (loading the initial state of the page).
3. The presenter works with our domain objects (the model) to get a list of people.
4. The presenter then passes the newly acquired list of people to the view by calling appropriate method provided by the view.
5. The view then attaches the list of people to the data source of a repeater and asks the repeater to bind on that list.

If someone were to click on a person in that list, the process would be repeated up through the view, into the presenter, over some domain objects, and back down to the view.