I can't see the difference between MVC and MVVM clearly. I feel the Command in a ViewModel is just like the Action method in a Controller. And both the Controller and ViewModel will notify the View to refresh itself after modifying the state of the Model through Data Binding. What is the main difference between the two patterns?
MVC vs MVVM – Difference Between Controller and ViewModel
asp.netdesign-patternssilverlight
Related Solutions
Navigation should always be handled in the ViewModel.
You're on the right track with thinking that the perfect implementation of the MVVM design pattern would mean you could run your application entirely without Views, and you can't do that if your Views control your Navigation.
I usually have an ApplicationViewModel, or ShellViewModel, which handles the overall state of my application. This includes the CurrentPage (which is a ViewModel) and the code for handling ChangePageEvents. (It's often also used for other application-wide objects such as the CurrentUser, or ErrorMessages too)
So if any ViewModel, anywhere, broadcasts a ChangePageEvent(new SomePageViewModel), the ShellViewModel will pickup that message and switch the CurrentPage to whatever page was specified in the message.
I actually wrote a blog post about Navigation with MVVM if you're interested
The user interacts with the View, but the View must communicate the actions to the Controller. The Controller may update the Model, but it isn't required with every/any change.
The description I am providing is based on my personal experience with the .NET implementation of MVC. Your implementation can be different.
The Controller is where actions are processed, basically a business layer. A simple controller will do nothing more than get the data from the Model to feed to the View. A complicated Controller will perform all sorts of actions, up to security management, authentication, authorization, registration, and possibly many other things.
The View should only be responsible for displaying the information in a fashion that the user can understand. There can be some cross over here with both the Controller and the Model as things like Single Page Applications (SPAs) will have data validation feedback for the user. Any other cross overs are heavily frowned upon.
The Model deals with data. This includes validation of data (where applicable). Data storage and retrieval is also handled in this layer.
UPDATE
There seems to be some confusion surrounding who does what when. I included two different overviews of the MVC architectures because they are similar, but not the same. There is room for either interpretation. Possibly, many more. The descriptions above are my interpretation of MVC from multiple sources, including my own experience building applications using this methodology. Hopefully, this update will help to clear up some of this confusion.
MVC is an attempt to build a Separation of Concerns design pattern for software development. It has primarily been implemented in web based applications (to my knowledge).
The View handles all of the user interaction. If your user clicks on a button, the View determines if the click is a user interface interaction or something that is beyond its concern (a Controller interaction). If the button does something like copy values from one field to another, your implementation will determine if that is a View concern or a Controller concern. You will most likely only have this blurring of concerns when dealing with a Single Page Application (SPA).
The Controller is where your actions are processed. The View has communicated the user decided to change values for some fields. The Controller may perform validation on that data or it may be handled by the Model. Again this is implementation dependent. If the Controller has security features, it may determine that the user doesn't have sufficient privileges to perform the action. It would reject the changes and update the View accordingly. The Controller also determines what data to retrieve from the Model, how to package it, and update the View with that data.
The Model determines how and where to store data. It may also perform validation of that data before storing it (it should do this because people will bypass the View on occasion).
Wikipedia has an article on MVC.
- A model notifies its associated view/views and controllers when there has been a change in its state. This notification allows views to update their presentation, and the controllers to change the available set of commands. In some cases an MVC implementation might instead be "passive," so that other components must poll the model for updates rather than being notified.
- A view is told by the controller all the information it needs for generating an output representation to the user. It can also provide generic mechanisms to inform the controller of user input.
- A controller can send commands to the model to update the model's state (e.g., editing a document). It can also send commands to its associated view to change the view's presentation of the model (e.g., by scrolling through a document).
From Microsoft's Overview of MVC.
Models. Model objects are the parts of the application that implement the logic for the application's data domain. Often, model objects retrieve and store model state in a database. For example, a Product object might retrieve information from a database, operate on it, and then write updated information back to a Products table in a SQL Server database.
In small applications, the model is often a conceptual separation instead of a physical one. For example, if the application only reads a dataset and sends it to the view, the application does not have a physical model layer and associated classes. In that case, the dataset takes on the role of a model object.
Views. Views are the components that display the application's user interface (UI). Typically, this UI is created from the model data. An example would be an edit view of a Products table that displays text boxes, drop-down lists, and check boxes based on the current state of a Product object.
Controllers. Controllers are the components that handle user interaction, work with the model, and ultimately select a view to render that displays UI. In an MVC application, the view only displays information; the controller handles and responds to user input and interaction. For example, the controller handles query-string values, and passes these values to the model, which in turn might use these values to query the database.
Related Topic
- MVVM – Evaluating the Representation of the MVVM Pattern in Diagrams
- MVP Design Pattern – Does the View Update the Model?
- MVC and RESTful API – How to Integrate
- C# – Is it Right to Have Dependencies to ViewModel from Data Access Layer and View Layer?
- C# – Is it good practice to save an entire ViewModel in Session (C# ASP.NET MVC)
Best Answer
The controller and the ViewModel differ in various ways.
In MVC the Controller knows the view, it can change the View. It also knows the Model and can call it. In MVVM a ViewModel is an abstract representation of the View and does not know the concrete UI, it wraps the Model in a way so that it can be displayed as desired.
In classical MVC, a controller is just a strategy of the View to interact with the Model. In fact, sometimes a Controller isn't even necessary. In MVVM you don't need it, as you can have different ViewModels for the same View if you need different behaviours. In MVC you could have for example a ReadOnlyController or an AdminController to communicate with the Model. In MVVM you could just have two ViewModels and you choose the one you need for the View.
But they do have some similarities. In both patterns, the View is an observer. In classical MVC, the view is an observer of the model, in MVVM it's an observer of the ViewModel.
Both patterns are meant to provide a separation of concerns. MVVM primarily aims to provide an abstraction of the View, completely independent of the UI technology in use. MVC does not go that far. It's primary focus is on separation of concerns, so that you don't put business logic (the Model) into the view.
You might also find this answer of mine to a similar question helpful.
At last, I should say that both patterns belong to the same family. MVP, of which MVVM is a descendant is a sibling of MVC. If you want to know more follow this link to Martin Fowler's website, he explains everyting in detail.