>Interesting link.
>Skipping the whole 'Vietnam war' analogy he has some good anti-ORM arguments. But often (for example with object queries) he spends three or four paragraphs hi-lighting one potential shortcoming only to point out in the next three paragraphs that there are alternatives that avoid the problem.
>
>And, of course, the whole article is devoted to pointing out these ORM problems with no reference to other, equally problem-ridden, alternative strategies.
>
>Actually, I've always found it odd that taking a well-designed relational datbase and then, as soon as you issue a join, flattening the whole thing out again is not regarded as an impedence mismatch ?

Also, since this was written in 2006 it spoke to the tools available at the time as well as the conceptual model ( of the idea of ORM, not in the EDM sense ).

In Julia's first edition of her EF book she lists the heartbreakers of EF in the 3.5 and then in her 4.0 stuff talks about how they had for the most part been addressed.

But the remaining "adventures" in the current MS implementation are still a highly esoteric area for those of us who are just trying to use the damn thing to write apps. That is *why* I'm a big framework guy and leaning toward DevForce as being a way of being shielded from some of my own ignorance. Like VFE in VFP to SQL use, and Strataframe in using Winforms it is nice to have people who have pulled out their own hair dealing with issues I didn't even know were issues and giving me a higher level implementation. I don't know if what they do is perfect but I know it is a lot closer to it than what I'm going to put together 'rolling my own' <g>

One of the important points I'm seeing in the Devforce implementation is decoupling of the Entity Server - which actually deals with EF as a server side manager - and the EntityManager which is a local object cache that can function disconnected. I'm not 100% up to speed on the implications, but I'm very excited about the design as it just makes good sense to me on its face. ( Strataframe has a similar thing in their Enterprise Server for business objects but it is a separately licensed server product, and deals only with SF business objects in a winforms/sql db environment )



>
>>Interestingly, in June, 2006, Ted Neward blogged about ORM as being the Vietnam of Computer Science.
>>
>>He took alot of shots because of that post, but then followed up with additional Thoughts on Vietnam Commentary. What he said there was "And, although I will likely gather some serious heat for saying this, Visual FoxPro may have some of the most interesting "best of both worlds" mojo in the entire language space on this subject."
>>
>>It doesn't surprise me that Julie understands EF the way she does because of her FoxPro background.
>>
>>>In 1995 when they roled out the "new paradigm" of OOP Booth and Speedy and the other evangelists were showing objects talking to each other and objects defined based on use case roles etc and no one ever showed a practical way to actually do those kind of object in VFP. Everything everyboyd wrote in VFP was RDMS code (at best - most of what I got called in to fix was bad dBase or FPD FPW code) with properties and methods (maybe) and in the more sophisticated frameworks business "objects" etc. that at least allowed for good n-tier design But the model was based on the RDMS tables.
>>>
>>>The "entities" that were part of the original discussion just never materialized. I remember about 2000 somebody talking about ORM ( the missing piece ) and it made no sense to me at all.
>>>
>>>Then when there was talk of EF and nHibernate etc I started to see what they were talking about, but it still seemed an immature technology or at least tool set. Then came 4.0.
>>>
>>>For some reason once I "got" the terminology - especially "navigation" things really started to click. The ORM was built in ( Julia's videos on creating the EDM from Database and then the reverse really brought that around for me ), the LINQ suddenly seemed useful and then Ideablade's docs answered a lot o fmy questions about what I thought might cripple n-tier deployment. (the stuff they do with a disconnected entity cache really opens up some possibilities.)
>>>
>>>I've been chugging along with Winforms and VB and Strataframe business objects that are very powerful and very well designed for Winforms and apps that work like my VFE apps worked. Good stuff. But it won't translate well to WPF and would require a *lot* of rethinking. MS seems to indicate EF is the direction they had in mind with WPF and I think with VS 2010 it's pretty obvious WPF is where .NET development is going. ( one .net wasn't scarey the transition to C# was remarkably easy - got tired of looking at LINQ examples and having to try to translate.)
>>>
>>>WPF makes more sense to me than any UI implementation I've ever seen so I'll play. Between Blend and DevExpress WPF controls the weak link is just my own design skills ( and the temptation to put in waaay more sizzle than I need just because I *can* <g> The old "I've got a Mac with 50 fonts - and here's a ransom note" syndrome )
>>>
>>>This stuff is fun again.