MVP Defined
MVP is a derivative of MVC aimed at providing a cleaner separation between the view, the model, and the controller. The most relevant change from MVC is that view and model are physically separated and have no intimate knowledge of each other. The controller (renamed as presenter) is a mediator between the user and the application. Solicited by the view, it performs any work associated with the request and passes data back to the view. In MVP, the controller class is essentially responsible for presenting data to the view, which explains the new name of “presenter.”
Generalities of the MVP Pattern
As mentioned, in MVP the view and the model are neatly separated, and the view exposes a contract through which the presenter can read input values and provide results of the action.
Summarizing the situation further, we can say that MVP is a refinement of MVC based on three facts:
■ The view doesn’t know the model.
■ The presenter ignores any UI technology behind the view.
Comparison of MVC and MVP graphically
In theory, it could be an ASP.NET page as well as a Windows Forms window. The model in MVP, therefore, is the interface that the view object implements. Being an interface, it can include properties, but it can also include methods and events. In a Web Forms scenario, events are not required, and most of the time it will contain just properties.
Role of the View
The view is the Web Forms page that you build. This view is typically an instance of a class that inherits from Page or UserControl and implements the model. The view also holds a reference to an instance of the presenter. Between views and presenters, you typically have a one-to-one cardinality, even though you can still reduce the number of presenter classes by creating some sort of hierarchy and reusing a bit of code.
Role of the Presenter
The presenter is just an additional layer you build on top of code-behind classes. It is a class that can be easily designed to have no hidden dependencies. The presenter requires a reference on the view, but thanks to the contracted interface of the view the reference can be injected. The presenter will use the view object to grab input values and prepare a call to the middle tier. After the response has been received, the presenter will pass data back to the view, always through the members of the interface. As mentioned, the interface that abstracts the view is logically equivalent to the model in MVC. you can check it at MSDN at Model-View-Presenter Pattern
Web Forms and the MVP Pattern
MVP lends itself very well to being implemented in Web Forms. The pattern can be easily outlined as a step-by-step procedure and doesn’t require you to twist the Web Forms programming model. As a developer, you only need to add a bit of abstraction to your Web Forms pages to gain the benefits of the MVP pattern—testability and maintainability.
Having said that, I also feel obliged to mention that MVP is not a pattern for everyone and for just any application. MVP provides guidance on how to manage heaps of views and, quite obviously, comes at a cost—the cost of increased complexity in the application code. As you can imagine, these costs are easier to absorb in large applications than in simple ones. MVP, therefore, is not just for any application.
In MVP, the view is defined through an interface, and this interface is the only point of contact between the system and the view. As an architect, after you’ve abstracted a view with an interface, you can give developers the green light to start developing presentation logic without waiting for designers to produce the graphics. After developers have interfaces, they can start coding and interfaces can be extracted from user stories, if not from full specifications.
MVP is an important presentation pattern that can be a bit expensive to implement in relatively simple applications. On the other hand, MVP shines in enterprise-class applications, where you really need to reuse as much presentation logic as possible, across multiple platforms and in Software-as-a-Service (SaaS) scenarios. And many of these applications have an ASP.NET Web Forms front end.
Generalities of the MVP Pattern
As mentioned, in MVP the view and the model are neatly separated, and the view exposes a contract through which the presenter can read input values and provide results of the action.
Summarizing the situation further, we can say that MVP is a refinement of MVC based on three facts:
■ The view doesn’t know the model.
■ The presenter ignores any UI technology behind the view.
■ Abstracted to an interface, the view is easy to mock up, which makes testing the controller far easier.
The presenter is at the center of the universe and incorporates the presentation logic behind the view. The presenter in MVP is logically bound to the view, which is another reason for emphasizing the presentation role of the component. ASP.Net MVP Framework
Role of the Model
The best possible definition of the model doesn’t change in MVP. The model is the representation
of the data being worked on in the view. The above figure exposes a contracted interface, which represents the core functionality of the view to the presenter’s eyes. In other words, the presenter should be able to work with any object that implements that contracted interface.In theory, it could be an ASP.NET page as well as a Windows Forms window. The model in MVP, therefore, is the interface that the view object implements. Being an interface, it can include properties, but it can also include methods and events. In a Web Forms scenario, events are not required, and most of the time it will contain just properties.
Role of the View
The view is the Web Forms page that you build. This view is typically an instance of a class that inherits from Page or UserControl and implements the model. The view also holds a reference to an instance of the presenter. Between views and presenters, you typically have a one-to-one cardinality, even though you can still reduce the number of presenter classes by creating some sort of hierarchy and reusing a bit of code.
Role of the Presenter
The presenter is just an additional layer you build on top of code-behind classes. It is a class that can be easily designed to have no hidden dependencies. The presenter requires a reference on the view, but thanks to the contracted interface of the view the reference can be injected. The presenter will use the view object to grab input values and prepare a call to the middle tier. After the response has been received, the presenter will pass data back to the view, always through the members of the interface. As mentioned, the interface that abstracts the view is logically equivalent to the model in MVC. you can check it at MSDN at Model-View-Presenter Pattern
Web Forms and the MVP Pattern
MVP lends itself very well to being implemented in Web Forms. The pattern can be easily outlined as a step-by-step procedure and doesn’t require you to twist the Web Forms programming model. As a developer, you only need to add a bit of abstraction to your Web Forms pages to gain the benefits of the MVP pattern—testability and maintainability.
Having said that, I also feel obliged to mention that MVP is not a pattern for everyone and for just any application. MVP provides guidance on how to manage heaps of views and, quite obviously, comes at a cost—the cost of increased complexity in the application code. As you can imagine, these costs are easier to absorb in large applications than in simple ones. MVP, therefore, is not just for any application.
In MVP, the view is defined through an interface, and this interface is the only point of contact between the system and the view. As an architect, after you’ve abstracted a view with an interface, you can give developers the green light to start developing presentation logic without waiting for designers to produce the graphics. After developers have interfaces, they can start coding and interfaces can be extracted from user stories, if not from full specifications.
MVP is an important presentation pattern that can be a bit expensive to implement in relatively simple applications. On the other hand, MVP shines in enterprise-class applications, where you really need to reuse as much presentation logic as possible, across multiple platforms and in Software-as-a-Service (SaaS) scenarios. And many of these applications have an ASP.NET Web Forms front end.
Please Read the below article for details.
Comments
Post a Comment