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.