What is a ViewModel?

A ViewModel is one of the three parts that comprises the MVVM (Model View View-Model). This pattern is a variation of the Presentation Model (M. Fowler). In the Presentation Model, as opposed to Passive View, the "controller" doesn't hold any reference to the view - and it isn't called "controller" but "Presentation Model". The View is the one which references the Presentation Model. The Presentation Model communicates changes to the View through events and data-binding. The View handles GUI events (user interaction) and may invoke methods on the Presentation Model.

In 2005, John Gossman from Microsoft introduced the MVVM pattern which has been evolving since then. In this post Josh Smith explains the pattern as it's commonly used today with an example. According to this post, a ViewModel is an object which wraps a model (CustomerViewModel contains a Customer model inside). However the another ViewModel is the MainWindowsViewModel, an abstract representation of the MainWindow. So there you go, the same term is used for two different things. So what is a ViewModel?

In this other example by Jeremy Likness, there is a class called Contact which he says is a Model, a domain model. I bet that to some people Contact is rather a ViewModel - specially given its implementation of INotifyPropertyChanged.  This is getting more and more confusing!

In our team, a ViewModel is the class handling all the logic related to the GUI. It acts as an Application Service, the entry point to the hexagon. I believe that in his book, Vaughn Vernon discourages the reader from using this kind of "controller" as an application service. But we haven't encounter any good reason not to use it as such. In fact, I find the definition of application service quite contradictory in that book. We never expose domain models directly to the GUI. We may wrap domain models into other objects which in turn are bounded to the GUI (data-binding) and implement interfaces like INotifyPropertyChanged. Although more often than not, our domain models are not even there. These objects are definitely a kind of "view" of the model, I was tempted to call them "ModelView". I understand they may be called ViewModels, it's reasonable. In some articles thew ViewModel is more model-ish than view-ish. Nonetheless to avoid the dilemma of calling these objects ViewModels, we decided not to add the suffix *ViewModel to them. We simply keep them under the *.ViewModel namespace but they are just objects - a Vehicle, a Customer...
What we definitely know is that they are not domain models. They are anemic models to support a particular view of the application. They should not hold references to other services. The application service (what we call ViewModel) holds the references to these data bounded objects in order to get the information from the user.

It's important is to remember the Presentation Model. It does not make calls to the view, it should not have references to any view component. If the GUI logic requires to pop up a confirmation dialog, the Presentation Model (ViewModel) should not make a direct call to some kind of "Dialog", it should rather trigger an event that the View can listen to show up the dialog.

What do you think? I appreciate your comments and thoughts 😉





  • Modesto San Juan

    I also like to think in ViewModels as a Model for the presentation. I’ve read a lot of articles and blog posts talking about ViewModels working together with domain models where the domain models implements INotifyPropertyChanged, IDataErrorInfo, etc. As an example: https://msdn.microsoft.com/en-us/library/gg405484(v=pandp.40).aspx

    I think mixing the presentation model with the domain model is a mistake. I don’t want a dirty domain model (inside the hexagon) only because I want to apply observer pattern from the presentation (outside the hexagon).

    All UI applications have UI business. This kind of business is what I think must be managed from de ViewModel and it’s fully justified to have some presentation model classes that work together with ViewModels to achieve them.

    Of course, part of this Business includes the interaction with the domain. This is the moment when the ViewModel must act as an Application Service or use an Application Service. I think that the difference between act as an Application Service or call to an Application Service depends on multiple factors. As an example, if we want to allow the user to do the same task from multiple places in our application, perhaps to use an Application Service it’s a better solution.

  • Himar Carmona

    I would like to add a reference to Dan Crevier’s explanation (code oriented) about these matters:


    This reference has now a lot of years (at last, i found it!), but explains MVVM very well. The names are a little more convoluted, but the patterns are perfectly identificable.

    Carlos, as always, a very good explanation. Thank you!

  • Miguel Serrano

    There’s one fantastic advantage using Presentation Model-based presenters and a DI container: you’re able to instantiate a headless version of your app in a single call. This is invaluable when it comes to implement fast and reliable user acceptance tests.

    In order to do this you have to architect your app in a way UI management lays outside the DI container. The view flow is managed separately, and views request PM instances from the container once they’re created or added to the stage.

    Since PM mimics the UI and have 1:1 mapping with views, actions performed and assertions made on your PM entirely reflect user interactions. Your tests will be fairly easy to read and maintain.


  • Miguel Serrano

    Regarding exposing domain object or not to the view, It’s important to be aware of the risks of doing this, but I don’t think such separation have to be enforced in every single case.

    My current projects involves more than 10 engineers but is quite homogeneous. We have some UI components making use not only of domain entities, but even DTOs. As long as the basic communication streams (C->M->P->V and other way round) are not broken, we kind of feel safe. When such DTO doesn’t fit in the model or in the view (normally for lack of cohesion), it’s time to create a separate, more suitable data type. But that’s just regular OOP I’d say.

    EDIT: probably worth to share that I’ve some experience on strict separation of data types between DTOs, Domain and Presenter layers. It resulted on a data type explosion, and I’m still not sure if it caused more harm than good. The project succeeded though.