Got it...

A couple of thoughts..
- How often does anyone write code and get it "right" the first time? We learn new ways and find new patterns that can be applied. Sometimes the environment changes requiring new code. I've done this and in the end, the new code didn't do anything new, it just did the same thing differently. Other times, what works in one application won't work as well in another. There's nothing wrong with DataSets. EF is just a different way. It extrapolates a lot of the plumbing work you had to do to make ADO.Net work. If you don't have that plumbing written, EF gets you up and running faster. ORMs are supposed to make things easier for the developer. That's the idea with EF. Does it make things easier for you? Maybe, maybe not.

- When EF first came out, it was panned. I looked at it as v1. I looked at it, paid attention to where it was going. Today, EF is pretty robust. Can you write better SQL query code yourself? In some cases, you probably can, but for the majority of queries, EF does a good enough job.

- Just because EF is the current flavor of choice doesn't mean it's all you can use. We have an ERP system that is REALLY difficult to model with EF so I use ADO.NET. I have apps that use both EF and ADO.Net to access the ERP data and EF for my application data. Use the tool that makes the most sense.

- I don't think I've ever said to use EF over ADO.Net.


>Yes, Craig, thank you, I know that :)
>
>Let me try this again.
>
>Historically, there is a pattern with the Microsoft development tools (and I'm sure other vendors have similar situations) that goes like this:
>
>1) Developers need to accomplish a set of tasks.
>2) The current tools have some functionality (that might be good, or barely OK), and requires some additional code and elbow grease.
>3) Developers crafts solutions, share ideas on how they accomplished it.
>4) Next release of the tool, the vendor implements new functionality that would have made lives easier and maybe would have precluded the need for additional hoops.
>
>Now, depending on how good the new feature is in #4, developers might be saying, "geez, if we had this back in #2, we never would have needed all this extra code. We should look at expending some developer bandwidth to rebuild our stuff with this new feature.
>
>OR...developers might look at #4 and say, "ok, this is nice, but we accomplished the same thing back in #2 with additional code, and this new stuff in #4 doesn't really buy us anything significant. Maybe we'll do a partial rewrite in a year and maybe we won't.
>
>I dare say that a large number looked at WCF and had the reaction of the former.
>I also dare say that a slightly larger % looked at EF and had a reaction a little closer to the latter.
>
>Mind you, I have nothing negative to say about EF. I just don't see the compelling benefit of it, the way I saw the compelling benefit of WCF.
>
>I realize this is branching out from the original topic. My only point is that there's a long history of new features coming along to replace older features that might have required more code and elbow grease. And sometimes the topic is quite controversial. Some people hate database triggers and loved the idea of Change Data Capture in sql 2008. Others looked at CDC and concluded , "thanks but no thanks, I think I'll stick to my triggers".