Fat Models, skinny ViewModels and dumb Views, the best MVVM approach?
Here's my opinion, for what it's worth :
I don't really agree with the approach you suggest (except for the dumb view). In real life, you will often have to use an existing model : it could be legacy code that you don't have the time (or will) to change, or even a library for which you don't have the code. In my opinion, the model should be completely unaware of the way it will be displayed, and should be easily usable in a non-WPF application. So it doesn't have to implement any specific interface like INotifyPropertyChanged of INotifyCollectionChanged to make it usable in MVVM. I think that all the logic related to UI should reside in the ViewModel.
Regarding RoutedEvents and RoutedCommands, they are not really suitable for use with the MVVM pattern. I usually try to use as little RoutedEvents as possible, and no RoutedCommands at all. Instead, my ViewModels expose RelayCommand properties that I bind to the UI in XAML (see this article by Josh Smith for details on RelayCommand). When I really need to handle events for some control, I use attached behaviors to map the events to ViewModel commands (have a look at Marlon Grech's implementation)
So, in summary :
- Dumb View
- Big and smart ViewModel
- Any model you want or have to use
Of course it's just my approach, and it may not be the best, but I feel quite comfortable with it ;)
I agree with Thomas.My advise to anyone on WPF architecturing would be:
- Plain POCO entities with no INotifyPropertyChange, state tracking, BL, etc.
- Simple and small ViewModels that notify Views just-in-time
- Simple reusable UI with a smart navigation system that avoid complex data hierarchies and complex underlying ViewModels
- MVVM with View First approach to keep dependencies simple
- Async operations with Tasks or Rx
- A simple theme
- No complex robust UI, keep it simple, just take advantage of WPFs UI composition and binding capabilities
- Don't hesitate to use code-behind to generate content dynamically (forms, lists etc) and save significant time on declarative eye configuration (applies to most cases) - and for me a must on 2015. Use extension methods to create a Fluent API for that.