Why do we need Models when we could:

  1. Only get the data (which is to be displayed)
  2. Populate the ViewModel with this data
  3. Pass this ViewModel into the View
  • 3
    "Only get the data (which is to be displayed" -- and what do you think this item would be? – whatsisname Mar 23 at 21:57
  • so, for example, if we have two tables in our Database - Student and Course (1 student studies 1course; 1course can be studied by many students) and we want to display students' full name and the title of the course that they are studying, can't we just have a viewModel with firstname, lastname and courseTitle as properties, as opposed to having a Student, Course and ViewModel classes? – user7519189 Mar 23 at 22:06
  • 2
    The ViewModel must under no circumstances access those tables. So yes, you can have a ViewModel with those fields. But that view model is then created from Student and Course models, which are allowed to talk to the database. – David Arno Mar 23 at 22:32
  • 1
    Recommended reading (if not a duplicate): softwareengineering.stackexchange.com/questions/159207/… – Greg Burghardt Mar 23 at 23:52
  • Just wanted to point out (since the asp.net tag has been deleted) that this question is about ASP.NET MVC, meaning that 1) it's not about the classical MVC/MVP and similar patterns, but rather the web version of MVC, and 2) the ViewModels in this framework are just simple data structures with essentially no behavior used to transfer data from controllers into the view rendering engine (view/page templates). – Filip Milovanović Mar 24 at 8:28

Having a Model and a ViewModel promotes separation of concerns by allowing your Model to work independently from the rest of your system.

Have a look at the following architecture:

{Database} --> {Data Access Layer (DAL)} --> {Model} --> {ViewModel} --> {View}

The arrows show the direction of dependency travel. The principle illustrated here is that dependencies flow in only one direction. For example, the View knows about the ViewModel, but the ViewModel knows nothing about the View. Correspondingly, it's better if the ViewModel doesn't have to concern itself with database access, so it defers this responsibility to the Model.

The purpose of the ViewModel is to provide a surface with which the View can interact. This allows the view to focus solely on displaying data, and allows the developer to push most of the code out of the UI into the ViewModel. This is done for a number of reasons, but the most important one is that it allows the ViewModel to be treated like an ordinary class; i.e. it makes it unit-testable.

The purpose of the Model is to provide a surface with which the ViewModel can interact with the database indirectly, from a business domain perspective. For example, if you have a form that displays an Invoice, it's more convenient from the ViewModel's perspective to allow the Model to assemble a business object that contains all of the data needed to populate an invoice, than it is for the ViewModel to get all of the pieces of information from the database directly. The ViewModel doesn't need to know anything about the database; it just needs to be provided the right data.

Providing separate layers like this is a lot like any other refactoring. Take Extract Method, for example. If you find yourself repeating the same code more than twice, it's better to put that code in a new method and call the new method instead of repeating the same code.

Surely, if you have a UI that only has one specific purpose (a security dialog, perhaps?), it's a small dialog and you know that the database access code is simple and will never be used anywhere else, then it might make sense to put it in the ViewModel and access the DAL directly. You can put your database access code in there if you like, so long as you understand that it will be tied to that specific ViewModel; i.e. it will not be reusable.

But most of the time, for non-trivial UI, I think you'll find that it always makes more sense to provide a first-class Model object.


The data in your step 1. is the model.

The "model" in MVC does not refer to some MVC-specific component but rather to any data structure or object you plug into the viewmodel or directly into the view+controller.


[By memory. I don't have the book in front of me at the moment.]

Martin Fowler in his book Patterns of Enterprise Application Architecture (PoEAA) discusses the Document-View, MVC, MVP(SC), MVP(PV), MVVM, and other MVx patterns. He remarks that it's easy to spot the divide between the responsibilities of the View and the rest. Everyone easily arrives to approximately the same conclusion, and there's consensus. The rest of the split (i.e. the split between Model and ViewModel, or presenter, or controller, etc) is less apparent.

Long time ago, the Document-View pattern was in use. The Document object lumped responsibilities of both Model and ViewModel.

A ViewModel with some responsibilities of a model could be somewhat viable for a very small and short project. Be aware that you are probably incurring some technical debt. Be prepared that you may need to factor out the model.


First of all, Model is not just what you mean. Entity Model, View Model, Data Transfer Object(DTO) are all kind of a Model.

We need these kind of Models, because we need to separate our project as layers. That's why we call them by different names. User Interface(UI) uses View Models to show data from UI. Business Logic Layer(BLL) uses Domain Models to manage business. Data Access Layer(DLL) use Entity Models to get data.

If you use View Models to fetch data from db, you need to write all your code each time you access same table for another View Model(because View Models may have same table and columns). If your View Models change, then your db access code should change.

Also, you can not use your same codes for another UI layer(for example for mobile). There are many reason that why you should not do that. Shortly, this is bad practice. Beyond this, there are many security reasons such as querying, validations.

Separate your layers and use proper models for each layer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.