Question

I’m used to working in WPF with the MVVM design pattern, but I’ve recently been asked to do something in ASP.Net. I’d like to try using MVC because I saw it referenced a lot when learning MVVM, however I don’t know anything about it.

I can find plenty of sites that are meant to explain MVVM to someone who is familiar with MVC, however I cannot find a good one that explains MVC to someone who is used to MVVM. There are sites that explain MVC on it’s own, but I’m having a hard time understanding them because my mind keeps trying to apply MVVM logic.

So, are there any good sites that can explain MVC in terms that someone used to MVVM can understand? Or can someone explain it to me here?

Answer 1

When you come from MVVM pattern and start with MVC pattern (especially ASP.NET MVC) I would suggest to think of the “MVC” pattern better as the “VMVC” because the “M” in MVC is not the Model meant by the “M” in MVVM. It actually corresponds to the ViewModel. I don’t know if that represents the general definition of MVC but it is true and the most used and best practice when you work with ASP.NET MVC (although you see every now and then examples or questions here on SO where domain entities are used in a view (which is sometimes exactly the reason for the problem described in the question)).

The first thing I usually do when I create a ASP.NET MVC project from one of the Visual Studio templates is to rename the created folder “Model” into “ViewModel”. If you take a look what the template code does with those “Models” you see that they are directly used for the views, that they have data annotations for input validation, for display formats and perhaps field naming on the view. These annotations are partially used directly by the HTML helpers to produce the HTML and don’t represent domain or business logic. In other words: they are ViewModels for an Razor/HTML view in the same sense as you use ViewModels in MVVM for your XAML views in WPF/Silverlight/Phone7.

The domain “Model” is actually not part of the MVC pattern as it is a part in the MVVM pattern. So, the abbreviations are somewhat misleading when you compare MVVM with MVC. As a very simplified “translation table” one could say:

MVVM                         MVC
----                         ---
M  -> Domain Model           not part of the pattern
V  -> View (XAML)            V -> View (HTML, Razor)
VM -> ViewModel              M -> ViewModel
not part of the pattern      C -> Controller

I’m not sure about the corresponding thing of a controller in MVVM. In MVC the controller is usually the module which translates domain objects into ViewModels and then into views (and vice versa) – schematically:

ControllerActionForGetRequest ( params )
{
     objects = GetDomainObject(params)    - entities, queryables or DTOs
     viewModel = CreateViewModelFromDomainObjects(objects)
     view = CreateViewFromViewModel(viewModel)
}

ControllerActionForPostRequest ( viewModel )
    // ModelBinder makes "viewModel" from HTML input fields, etc
{
     if (IsValid(viewModel))
     {
         data = CreateDomainObjectsOrDtosFromViewModel(viewModel)
         WriteData(data)  - back to data store
         RedirectToActionForGetRequest
     }
     else
         GoBackToView
}

Which part in MVVM has this responsibility? I am not sure. I have seen designs where the ViewModel holds some reference to a repository, pulls out the Model (Domain Model) to fill its own properties and writes back into the repository through ICommand handlers. That would mean that ViewModels in MVVM also have the responsibility to be a “controller” while ViewModels in MVC are much simpler: They are more or less only property bags with metadata to provide and format data for a view.

As a final note: Personally I found the MVVM pattern with WPF much more difficult to master than the MVC pattern. ASP.NET MVC is designed from the ground to support MVC pattern-friendly development and there is not need (or even not the possibilty) to leave this way. This is not the case for WPF. The original design was built with views and code-behind files in mind, not with the MVVM pattern. I found often situations where it was very difficult to bind view elements or attributes to a ViewModel and handling this in code-behing files was much easier, thereby violating MVVM principles a bit.

I would think that you won’t have any problems to get into MVC when you have experience with the MVVM pattern.