MVC vs MVP vs MVVM

MVC (Model-View-Controller)

MVC is an architectural design pattern that encourages improved application organization through a separation of concerns. It enforces the isolation of business data (Models) from user interfaces (Views), with a third component (Controllers) traditionally managing logic and user input.

MVC architecture:

• A Model represented domain-specific data and was ignorant of the user interface (Views and Controllers). When a model changed, it would inform its observers.

• A View represented the current state of a Model. The Observer pattern was used for letting the View know whenever the Model was updated or modified.

• Presentation was taken care of by the View, but there wasn't just a single View and Controller - a View-Controller pair was required for each section or element being displayed on the screen.

• The Controllers role in this pair was handling user interaction (such as key-presses and actions e.g. clicks), making decisions for the View.

Benefits of MVC:

• Maintainability. Easier overall maintenance. When updates need to be made to the application it is very clear whether the changes are data-centric, meaning changes to models and possibly controllers, or merely visual, meaning changes to views.

• Testability. Decoupling models and views means that it is significantly more straightforward to write unit tests for business logic

• Less code duplication. Duplication of low-level model and controller code (i.e what we may have been using instead) is eliminated across the application

• Independent development. Depending on the size of the application and separation of roles, this modularity allows developers responsible for core logic and developers working on the user interfaces to work simultaneously

MVP (Model-View-Presenter)

Model-view-presenter (MVP) is a derivative of the MVC design pattern which focuses on improving presentation logic.

The P in MVP stands for the presenter. It's a component that contains the user-interface business logic for the view. Unlike MVC, invocations from the view are delegated to the presenter, which is decoupled from the view and instead talks to it through an interface. This allows for all kinds of useful things such as being able to mock views in unit tests.

The most common implementation of MVP is one that uses a Passive View (a view which is for all intents and purposes "dumb"), containing little to no logic. If MVC and MVP are different it is because the C and P do different things. In MVP, the P observes models and updates views when models change. The P effectively binds models to views, a responsibility that was previously held by controllers in MVC.

Solicited by a view, presenters perform any work to do with user requests and pass data back to them. In this respect, they retrieve data, manipulate it and determine how the data should be displayed in the view. In some implementations, the presenter also interacts with a service layer to persist data (models). Models may trigger events but it's the presenter's role to subscribe to them so that it can update the view. In this passive architecture, we have no concept of direct data binding. Views expose setters which presenters can use to set data.

The benefit of this change from MVC is that it increases the testability of our application and provides a more clean separation between the view and the model. This isn't however without its costs as the lack of data binding support in the pattern can often mean having to take care of this task separately.

MVVM

As with other members of the MV* family, the Model in MVVM represents domain-specific data or information that our application will be working with. A typical example of domain-specific data might be a user account (e.g name, avatar, e-mail) or a music track (e.g title, year, album).

Models hold information, but typically don’t handle behavior. They don’t format information or influence how data appears in the browser as this isn’t their responsibility. Instead, formatting of data is handled by the View, whilst behavior is considered business logic that should be encapsulated in another layer that interacts with the Model - the ViewModel.

Pros and Cons

Pros:

• MVVM Facilitates easier parallel development of a UI and the building blocks that power it

• Abstracts the View and thus reduces the quantity of business logic (or glue) required in the code behind it

• The ViewModel can be easier to unit test than event-driven code

• The ViewModel (being more Model than View) can be tested without concerns of UI automation and interaction

Cons:

• For simpler UIs, MVVM can be overkill

• Whilst data-bindings can be declarative and nice to work with, they can be harder to debug than imperative code where we simply set breakpoints

• Data-bindings in non-trivial applications can create a lot of book-keeping. We also don’t want to end up in a situation where bindings are heavier than the objects being bound to

• In larger applications, it can be more difficult to design the ViewModel up front to get the necessary amount of generalization

MVC vs MVP vs MVVM

Both MVP and MVVM are derivatives of MVC. The key difference between it and its derivatives is the dependency each layer has on other layers as well as how tightly bound they are to each other.

In MVC, the View sits on top of our architecture with the controller beside it. Models sit below the controller and so our Views know about our controllers and controllers know about Models. Here, our Views have direct access to Models. Exposing the complete Model to the View however may have security and performance costs, depending on the complexity of our application. MVVM attempts to avoid these issues.

In MVP, the role of the controller is replaced with a Presenter. Presenters sit at the same level as views, listening to events from both the View and model and mediating the actions between them. Unlike MVVM, there isn’t a mechanism for binding Views to ViewModels, so we instead rely on each View implementing an interface allowing the Presenter to interact with the View.

MVVM consequently allows us to create View-specific subsets of a Model which can contain state and logic information, avoiding the need to expose the entire Model to a View. Unlike MVP’s Presenter, a ViewModel is not required to reference a View. The View can bind to properties on the ViewModel which in turn expose data contained in Models to the View. As we’ve mentioned, the abstraction of the View means there is less logic required in the code behind it.

One of the downsides to this however is that a level of interpretation is needed between the ViewModel and the View and this can have performance costs. The complexity of this interpretation can also vary - it can be as simple as copying data or as complex as manipulating them to a form we would like the View to see. MVC doesn’t have this problem as the whole Model is readily available and such manipulation can be avoided.