When you come from the MVVM pattern and start with the MVC pattern (especially ASP.NET MVC), I would suggest thinking of the “MVC” pattern better than “VMVC” because “M” in MVC is not an “M” model in MVVM This actually matches the ViewModel. I don’t know if this is a general definition of MVC, but it is true and most in demand and works best when working with ASP.NET MVC (although you see examples or questions here every time where SO is used in the view (which is sometimes the reason the problem described in the question)).
The first thing I usually do when I create an ASP.NET MVC project from one of the Visual Studio templates is to rename the created Model folder to ViewModel. If you look at what the template code does with these “Models,” you see that they are directly used for representations, that they have data annotations to validate input, for display formats, and possibly naming fields in the view. These annotations are partially used directly by HTML helpers to create HTML code and do not represent domain or business logic. In other words: they are ViewModels for Razor / HTML presentation in the same sense that you use ViewModels in MVVM for your XAML views in WPF / Silverlight / Phone7.
The Model domain is not really part of the MVC pattern, because it is part of the MVVM pattern. Thus, abbreviations are somewhat misleading when you compare MVVM to 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 am not sure about the corresponding function of the MVVM controller. In MVC, a controller is usually a module that 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 }
What part of the MVVM has this responsibility? I'm not sure. I saw projects in which the ViewModel contains some link to the repository, pulls out a model (domain model) to populate its own properties and write to the repository through ICommand handlers. This would mean that ViewModels in MVVM are also responsible for the “controller”, while ViewModels in MVC are much simpler: they are more or less property bags with metadata to provide and format the data for presentation.
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 up to support MVC-friendly development, and there is no need (or even not the ability) to leave this path. This does not apply to WPF. The original design was created taking into account the views and files with the code, and not with the MVVM template. I often encountered situations where it was very difficult to associate the elements or attributes of the view with the ViewModel, and processing this in code files was much easier, thereby violating the principles of MVVM a bit.
I would think that you would not have any problems getting into MVC when you have experience with the MVVM template.