Is the DataContext part of Model in MVC or a part of Controller?

Question

working on asp.net MVC from quite some time now
today stuck on a theoretical problem
going through some sample code on MSDN
I read something like this

public class SomeController()
{
 public ActionResult SomeAction(SomeModel model)
 {
   var dataContext = new SomeDataContext();
   //basic CRUD operations on data context
   //
 }
}

here the database obviously is being accessed through the controller and by theory is incorrect
is there something wrong with this example or my definition of what a model and what a controller is needs to be refreshed
UPDATE:-
or there is a possibility that every where on MSDN Models and ViewModels are considered equal

Answer 1

intro

MVC design pattern is quite old. It was originally defined for Smalltalk-80 applications, when "web" was two guys sending ping between universities. Since then it has evolved quite a lot.

The core principle behind MVC design pattern is Separation of Concerns. The pattern separates presentation from business logic. Presentation layer contains mostly views, controller, templates, viewmodels and presenters (depending on which flavor of MVC-inspired patterns you use), while business logic is ends in the model layer.

The model layer, while not strictly defines in the pattern, in ASP.NET MVC consists of services and all the structures that are used by service (including the Model Objects, better known as domain objects).

regarding the question

It is quite common to see DataContext uses in controllers, when you are looking for basic MVC tutorials. MVC architecture is meant of large scale applications, and in a Hello-World example a fully realized MVC architecture would look like just bloat.

The examples sacrifice code separation for sake of simplicity. The interaction with DataContext is basically storage logic, which is one of tasks that model layer handles. When used in controller, it means that your model layer has begun leaking in the presentation layer, and you end up with "Fat controller, skinny model" problem.

In a real world application the DataContext would be part of structure that deal with persistence within model layer. Probably as part of data mappers, if you opt to write them manually.

regarding "update"

The model (I suppose in this case you meant Domain/Model object) is from completely different application layer then ViewModel.

As the name implies, in MVVM pattern the ViewModels replace the Controllers. ViewModel acquired data from model layer, and then transforms it in such a way that is usable for View.

This pattern is best used (if you are really using MVVM) in situation when you do not have full control over behavior over Views or/and Model layer. For example: if you were hired to build an alternative frontend for SAP or when the view is actually some form of hardware device, which expects specific type of input.

Answer 2

The Models are typically the data classes (representing the database tables). The View Models are typically referred to as classes that have been created in order to use them in the view for presentation purposes.

You wouldn't be able to use the DataContext on a View Model in the above case, but you can use it perfectly fine with the above mentioned Model classes (also called DTO classes).

Answer 3

MVC is a GUI pattern, just like MVP or MVVM, it has nothing to do with data access and persistence. It's true that many simple CRUD applications are not much more that MVC and an underlying database, but in more complex applications MVC would be part of the presentation layer.

The DataContext as an O/RM belongs to the infrastructure layer, not the GUI. In MVC the Model can be understood as ViewModel, yes.

Nevertheless the controller can use the DataContext or any other means to retrieve this model from the underlying data store.