Nice and simple definition of WPF's MVVM

Question

What is the basic definition of the Model, View and ViewModel objects in WPF\'s MVVM design pattern? What are their responsibilities, what each of them should and shouldn\'t

Answer 1

Model:

1. Represents the Data.
2. The Entity.
3. Model classes are non-visual classes that encapsulate the application's data and business logic.
4. They are responsible for managing the application's data and for ensuring its consistency and validity by encapsulating the required business rules and data validation logic.
5. The model classes do not directly reference the view or view model classes and have no dependency on how they are implemented.
6. The model classes typically provide property and collection change notification events through the INotifyPropertyChanged and INotifyCollectionChanged interfaces.
7. This allows them to be easily data bound in the view.
8. Model classes that represent collections of objects typically derive from the ObservableCollection<T> class.
9. The model classes typically provide data validation and error reporting through either the IDataErrorInfo or INotifyDataErrorInfo interfaces.
10. The model classes are typically used in conjunction with a service or repository that encapsulates data access and caching.
11. Not required to know where it gets its data from i.e from a WCF service. WCF RIA Services, etc.
12. May contain validation.

View:

13. The view is a visual element, such as a window, page, user control, or data template.
14. The view defines the controls contained in the view and their look and feel, visual layout and styling.
15. The view references the view model through its DataContext property.
16. The controls in the view are data bound to the properties and commands exposed by the ViewModel.
17. The view may customize the data binding behavior between the view and the view model. For e.g, the view may use value converters to format the data to be displayed in the UI, or it may use validation rules to provide additional input data validation to the user.
18. The view defines and handles UI visual behavior, such as animations or transitions that may be triggered from a state change in the view model or via the user's interaction with the UI.
19. The view's code-behind may define UI logic to implement visual behavior that is difficult to express in XAML or that requires direct references to the specific UI controls defined in the view.

ViewModel:

20. The ViewModel is a non-visual class and does not derive from any WPF or Silverlight base class.
21. It encapsulates the presentation logic required to support a use case or user task in the application.
22. The ViewModel is testable independently of the view and the model.
23. The ViewModel typically does not directly reference the view. It will have UI Friendly Entities, UI State, Actions and Public properties that are bound to a View.
24. It implements properties and commands to which the view can data bind.
25. It notifies the view of any state changes via change notification events via the INotifyPropertyChanged and INotifyCollectionChanged interfaces.
26. Interacts with View with various Commands.
27. The view model coordinates the view's interaction with the model.
28. It may convert or manipulate data so that it can be easily consumed by the view and may implement additional properties that may not be present on the model.
29. It may also implement data validation via the IDataErrorInfo or INotifyDataErrorInfo interfaces.
30. The view model may define logical states that the view can represent visually to the user.
31. Invokes services to communicate outside the MVVM triad.

Source: http://code.msdn.microsoft.com/Design-Patterns-MVVM-Model-d4b512f0