MVVM vs MVC vs MVP - Explained

MVVM vs MVC vs MVP – Explained

The biggest difference between the design patterns seems to be who controls the application flow and logic.

In MVVM, your code classes (ViewModels) are your application, while your Views are just a pretty user-friendly interface that sits on top of the application code and allows users to interact with it. This means the ViewModels have a huge job, because they are your application, and are responsible for everything from application flow to business logic.

With MVC, your Views are your application, while your Controller handles application flow. Application logic is typically found in ViewModels, which are considered part of the M in MVC (sidenote: the M in MVC cannot be considered the same as the M in MVVM because MVC’s M layer contains more functionality than MVVM’s M layer). A user is given a screen (View), they interact with it then submit something to the Controller, and the Controller decides who does what with the data and returns a new View to the user.

MVP is very similar to MVC, but optimized for a desktop application instead of a client/server application. The Views are the actual application, while the Presenter handles application events and business logic.

Similar Elements

All three of the architectures are designed to separate the view from the model.
Model

• Domain entities & functionality


• Knows only about itself and not about views, controllers, etc.


• For some projects, it is simply a database and a simple DAO


• For some projects, it could be a database/file system, a set of entities, and a number of classes/libraries that provide additional logic to the entities (such as performing calculations, managing state, etc)

Your can Implement it by Creating classes that describe your domain and handle functionality. You probably should end up with a set of domain objects and a set of classes that manipulate those objects.

View

• Code that handles the display


• Note that view related code in the codebehind is allowed (see summery at the bottom for details)

Your can Implement it by Creating WPF, HTML/xHTML/HTML5, Windows Forms, views created programmatically. Basically code that deals with display/UI only

Differences (Controllers, Presenters, and ViewModels)

Some things that Controllers, Presenters, and ViewModels have in common are:

• Thin layers


• They communicate with the model and the view

The features:

Controllers

• The controller determines which view is displayed


• Events in the view trigger actions that the controller can use to modify the model or choose the next view.


• There could be multiple views for each controller


• View Communication:


• The controller has a method that determines which view gets displayed


• The view sends input events to the controller via a callback or registered handler. In the case of a website, the view sends events to the controller via a url that gets routed to the appropriate controller and controller method.


• The view receives updates directly from the model without having to go through the controller.
  Note: In practice, this particular feature of MVC is employed as often today as it was in the past. Now a days, I think developers are opting for MVVM (or MVP) over MVC in most situations where this feature of MVC would have been used. Websites are a situation where I think MVC is still a very practical solution.

Note:

• A class is required to interpret incoming requests and direct them to the appropriate controller. This can be done by just parsing the url. Asp.net MVC does it for you.


• If required, the controller updates the model based on the request.


• If required, the controller chooses the next view based on the request. This means the controller needs to have access to some class that can be used to display the appropriate view. Asp.net MVC provides a function to do this that is available in all controllers. You just need to pass the appropriate view name and data model.

Presenters

• 2 way communication with the view


• View Communication: The view communicates with the presenter by directly calling functions on an instance of the presenter. The presenter communicates with the view by talking to an interface implemented by the view.


• There is a single presenter for each view

Note:

• Every view’s codebehind implements some sort of IView interface. This interface has functions like displayErrorMessage(message:String), showCustomers(customers:IList), etc. When a function like showCustomers is called in the view, the appropriate items passed are added to the display. The presenter corresponding to the view has a reference to this interface which is passed via the constructor.


• In the view’s codebehind, an instance of the presenter is referenced. It may be instantiated in the code behind or somewhere else. Events are forwarded to the presenter through the codebehind. The view never passes view related code (such as controls, control event objects, etc) to the presenter.

ViewModels

• 2 way communication with the view


• The ViewModel represents the view. This means that fields in a view model usually match up more closely with the view than with the model.


• View Communication: There is no IView reference in the ViewModel. Instead, the view binds directly to the ViewModel. Because of the binding, changes in the view are automatically reflected in the ViewModel and changes in the ViewModel are automatically reflected in the view.


• There is a single ViewModel for each view.

Note:

• The view’s datacontext is set to the ViewModel. The controls in the view are bound to various members of the ViewModel.


• Exposed ViewModel proproperties implement some sort of observable interface that can be used to automatically update the view (With WPF this is INotifyPropertyChanged; with knockoutjs this is done with the functions ko.observable() and ko.observrableCollection())

MVVM vs MVC vs MVP - Explained