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.
There is no need to create a POCO mapping of a DataSet that is a member variable within a ViewModel, is there?
If the DAL hands you a ready made datatype, be it ADO Entity or a DataSet, why not use it in the ViewModel?
The ViewModel is, among other things, a land of normalizing data for UI consumption, so you can resurface the DataSet as a property from the ViewModel and bind the UI directly to it. Regardless of any protests, you've insured proper seperation of concerns
of UI and non-UI. If there is some business logic to perform on the data within the DataSet, you have it in your ViewModel read for processing...
Prism does have major plumbing ready to use, but sometimes it is also overkill for smaller applications. It is for composite applications, like those sporting plug-in architecture and painless deployment.
I would not hesitate to use a ViewModel class for the most mundane and small applications for the purpose of building a good habit as well as adding quality to your code via unit testing and re-use portablility.