I'm not so sure. I am now a full time WPF developer of sorts, and naturally I have a few pet projects in the pipeline. Coming from Windows Forms, I feel I could do the projects quicker and better but have stuck with WPF.
Recently I reviewed fully i.e. did the actual code sample of Josh Smiths famous article rather than blog about it. I then had to decide whether to use the Entity Framework, and that was
a resounding no because you have to create a POCO mapping to an ORM. Very stupid of the EF team, but this is addressed in VS 2010 (Guys a lot of WPF code has been written now and this is an oversight that ought not to have have happened)
The natural replacement is Linq, but that is now no longer in development which negates my (or anyone with any sense) election of it for a large project requiring maintenance, but it is the lesser of the two evils.
If you are going to use MVVM or MVP, then you may as well use Prism with the bootstrappers, Unity, Regions and Eventing. MVVM is great for testing, but in the real world that is only one minute aspect, people tend to
The only real issue is if you look at Josh Smith's article, however simple it might look, it actually is a very complicated bit of code. Not without its drawbacks, especially around exception handling.
I also think it completely wrong to use MVVM with a disconnected dataset, as that has all your change tracking already in it, only to create a POCO representation inheriting ObservableCollection. That is just plain wrong.
In general the dataset you return is your model-view, and passing that as a data context object in the "Window's" constructor and calling TableAdapterManager.UpdateAll() is in some ways just as
eloquent as MVVM. It's just that datasets are passe, but they do cut out a lot of ceremony with WPF and the MVVM. I would say use MVVM with ORM's only.