vesuvius said:
JohnAskew said:
*snip*

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 forget that!

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.

Hmm... lots in that post, while not giving enough "meat" to fully grok what you're saying.

In general, it seems your complaint is with EF and LINQ to SQL (not Linq as you said, because Linq is most certainly still under development), for various reasons.  Neither is relevant to MVVM, really.  Personally, I rarely do DB development, so my models don't come from an ORM. And, as you say, some ORMs don't have the issues you find in EF and LINQ to SQL, not to mention EF in 4.0 should address any of your concerns.

I'll agree that using the DataSet directly is problematic, but depending on many variables not presented here (need to bridge legacy code and size of application are a few things that come to mind), it may well be the best solution.  For those of us not using DBs, it's common to have to hand code various adapters for legacy APIs anyway, and MVVM is STILL a majorly useful pattern.