MVC vs MVP vs MVVM
MVC means Model View Controller, MVP means Model View Presenter, and MVVM means Model View ViewModel are architectural patterns that help structure our code. Each of these patterns has its unique way of splitting responsibilities and interactions between components.
Both the Model and the View are common elements in all three patterns.
Model
This is where the brainy, logical stuff happens. Whether it’s executing the logic for addition, fetching data from the database, processing data, or any other logical operation, it happens in the Model.
Analogy: This is like the “product” or the “inventory” in a store.
View
The View represents what we see on our screens. It’s purely concerned with presentation.
Analogy: This is like the “storefront” or “display shelf” where products are displayed for the buyer to see.
Controller, ViewModel, Presenter
These can be thought of as intermediaries or “salespersons” that bridge the gap between the seller (Model) and the buyers (View). They manage requests from the user, pass them to the appropriate models, and ensure updated models are returned to the view.
Analogy: the salesperson
So what makes them different? Let’s know about them in a few words.
MVC (Model View Controller)
Here the salespersons (Controller) won’t do anything, except present the property data to buyers. Handles the buyer’s request, interacts with the inventory (Model) to get or update product information, and shows the appropriate product to the buyer (View).
The controller doesn’t do any complicated stuff, the view sends the request to the controller, the controller passes it to the appropriate model, the updated model is sent back to the View and the View handles all the logic on how to present the model to the user. One controller can have many views, view is unaware of the controller.
MVP (Model View Presenter)
The Presenter is a step up from the Controller in terms of responsibilities. Here the salespersons (Presenter), will do all the things done by the controller and additionally, it also determines how the products are displayed. It will take requests from the buyer, interact with the Model to fetch or update data and instruct the View on what to display.
The Presenter controls the View, meaning the View is aware of its Presenter. Typically, there's a one-to-one relationship, with one View being controlled by one Presenter.
MVVM (Model View ViewModel)
The term to focus on here is data binding. At a high level, the view “knows about” the view model, and the view model “knows about” the model, but the model is unaware of the view model, and the view model is unaware of the view. Therefore, the view model isolates the view from the model and allows the model to evolve independently of the view[3]. In simpler terms, any UI event will trigger the view model, view model will ask the model for the data by sending commands or listening to events from the model, as soon as the model changes the view model changes the view because of binding.
Here multiple views can have the same view model. This pattern is more event-driven because of data binding.
For example: A user interacts with the View by typing into a text box (View). This change is reflected in a property in the ViewModel thanks to data binding. As a result of this change, the ViewModel might need to fetch some updated data. It sends a request to the Model. The Model processes the request and returns the necessary data. The ViewModel receives this data, possibly transforms or processes it, and updates its properties accordingly. The View, which is bound to the ViewModel’s properties, updates automatically to display this new data.
