Comparing MVC and MVP
Which one will be most beneficial for your upcoming project?
If you’re reading this article, it is likely that you are here for one of three reasons. One, you’re a new developer working predominately on the front end and are trying to do more research on architectural and design patterns. Two, you may have forgotten what a Most Valuable Player is. Or three, you’re an old Jersey Shore fan and were missing your Mike, Vinny, and Pauly fix. I’m just going to assume that you are here for the first point.
Before we dive too deep into comparisons, let’s touch a little bit on what architectural design patterns are, why they’re useful, and two of the most common onces which are MVP and MVC.
Architectural patterns are used to help developers design their code both inwards and outwards — meaning, how we are looking to structure the code inside a layer, but also how we are looking to process the requests between layers and back.
The reason why MVC and MVP are important is that they help us separate components, as well as differentiate between the layers that encompass UI features and layers that deal with backend and database layers. We will go into greater detail about how they work shortly.
MVC and MVP differ as architectural patterns from design patterns, as design patterns are smaller in scope and pretty localized, in turn having less of an impact on the code base. They will impact only a specific section of the code base, where MVC/MVP are larger scoped and are looking at the architecture of the program as a whole.
MVC Pattern
MVC is known for its three main parts — model, view, and controller — and these parts each hold a different concern, and all work together to distinguish between business, presentation, and control flow. Model handles state management, the controller responds to whatever the view is telling it to do, and the view renders UI elements onto the page.
MVP Pattern
MVP is a different pattern than MVC in the sense that it only works with the UI representation, meaning it doesn’t structure the whole system, just the view. MVP responsibilities are spread across 4 components. The view is responsible for rendering the UI elements, and the view interface couples the presenter from the view. The presenter interacts with view and model, with the model working closely to portray business behaviors and state management.
Now that we understand the basics, let’s talk about a few key differences between the two. However, something to understand is that there are not a lot of differences between the two, since they both do a great job at separating responsibility across components.
- The view and the model are less coupled in MVP than they are in MVC.
- MVC has little room for efficient testing, but it’s easier done in MVP.
- The controller is in charge for MVC, and the view is in charge in MVP.
- In discussing relationships between the patterns, a many to one relationship exists between the controller and the view in MVC. MVP has a one to one relationship.
- The controller handles user inputs in MVC and it tells the model what to do, however in MVP, the view handles user inputs and communicates with the presenter for functions.
In conclusion, it is up to you for what works best for you. MVP can help you create your application in modules which can make them more reusable and create less views. Play around with both and see what you enjoy most!
