2017  Kodetalk | Feedback | Privacy Policy | Terms | About

Introduction to MVP (model-view-presenter) or Passive View design pattern


The architectures, designers or the programmers are dealing with so many design patters like MVC, MVP, PM, MVVM etc now a days. There are multiple options to chose a best pattern before starting with the project design and development. So the question is, do we really required this or is really need these patterns in the first place over the application? Well one can certainly build software applications without using any of these patterns, but by using these patterns we can achieve separation of concerns design principle. These help in improving maintainability of the application. Another important reason why these patterns became popular is implementing these patterns improve the testability of the application using automated unit tests. We all know how difficult it is to write unit tests for UI tier, these patterns try to address some of these difficulties and provide a way of increasing application’s testability.


Here I will not going to start any comparison between any of the patterns available across the world.I will explain MVP design pattern, the benefits and some do's and don'ts in detail. Please note the content I put here by referring with find the best from the different different blogs, posts, faqs and the discussions to simply the architecture. So if you really interested to know more about MVP just refresh yourself and spend some time with this post.

Introduction to MVP

Model-view-presenter (MVP) is a software architectural pattern used in web, mobile, and other domains that incorporate UI. MVP aims to remove business logic from the UI and Model classes, making code more readable and easier to understand. It evolved from the more commonly used pattern, model-view-controller (MVC), in the early 1990s and because of this it is similar in design.

Definition of MVP

  • The Model Layer : The Model Layer represents the source of the data that we want to display on the View Layer.
  • The Presenter Layer : The Presenter is a class created solely to be the communicator between the View Layer and Model Layer.  The Presenter hosts methods which are utilized by the View Layer. The Presenter also hosts logic to return formatted data from the Model back to the View for display to the user.  
  • The View Layer : The View is usually represented by either an activity or fragment depending on the application’s approach.

I know its surprised right? what its talking about. But still some more here, so lets go to little deep to understand this.

Elaboration of the definition
In the MVP model, the data access objects constitute the model, the View is the UI components kept as simple as they can be and the Presenter is where the business logic is. These three components interact with other through interfaces to further reinforce the logical separation.

The presenter should have no idea where the Model gets its data or how the data is persisted. The Model defines an interface that must be implemented.   Anything that implements this interface can serve as the model.  This means that we can switch out the data storage strategy without having to change anything in the presenter.

The presenter should also have no idea about the nature of the View.The View implements an interface that exposes all of the methods, properties, and events that the Presenter will need and the Presenter implements the business logic through this interface. This means that View may actually been a Win Form, Web Form, a server control, a user control, a SharePoint web part, or even a class library with no UI components. The only requirement is that the View must implement the interface.

Do's and don'ts with MVP
  • Make sure that at all times the model is the "master" of it's data. This means that the View never should write directly to the fields of the model (anyway a bad idea). Properties is OK if your language supports them. This way, the model can still react on any updates to its data (e.g. by calculating another field).
  • Don't couple your model to the view. The model must be independently testable and in principle you should be able to change the view without affecting the model. This means the model should never directly call the view. Use interfaces, or probably best here, the Observer pattern. The View can subscribe itself to the model for updates.
  • Never put any (business) logic into the View. If you find yourself writing if statements in the view code, think about whether those should rather belong into the presenter or model.

Advantages or benefits
Starting with an MVP forces you to define your value proposition clearly, concretely, and (somewhat) narrowly. It forces you to examine the breadth and depth of your vision and to define exactly what value you want to provide to your ideal customer. You can then set clear targets, decide what really needs to be developed to test your value proposition, and spend your time and money efficiently.

Since I am not comparing this pattern with any other pattern, that's why one of the issues that surround here in general is there are several flavors and people new to the pattern get confused because each flavor has differing advantages and disadvantages. Its better you can take a look at these posts to help you understanding of the MVP and recollect some other pattern having the knowledge with deciding if it is for you or not.

Well that's all about from my side. Hope now you are in a position to understand what exactly MVP and the stuffs need to take care before start with this. Thank you have a good day.