Although I'm on vacation*, I've spent a little time reading the recently released ADO.NET NextGen whitepapers. I've also read some of the commentary from the ORM'ers since that is a technology that I have not used before. I've certainly been aware of them and that the ORM crowd has had to be a little over-the-top to try to be heard over Microsoft's spoon feeding DataSets to the rest of us "undiscerning" developers. I'm reading the whitepapers as a first pass just to see what Microsoft is doing and trying to digest them.. I find the criticisms from the ORMers educational, although they are even crankier than usual, so I have to read those with a grain of salt. Here are some to check out: Extra! Extra! - Microsoft to use 30 year old entity-data model in ADO.NET, http://www.ayende.com/Blog/2006/06/17/ADONetEntityFramework.aspx . Much of the latter is a cricitism of how the code samples were written as though he is worried a beginner is going to pick up this white paper and use it as a guide for best coding practices... but other comments are thought provoking.
So I like datasets a lot and use them a lot, though not everywhere and not religiously. I often just use them as a tool for getting stuff out of the database and into my own objects, which I could also do with a DataReader, but I find DataSets a little easier to navigate - and they were a more natural transition for me from VB6/ADO recordsets when I first started with .NET. On a very very high level, this is what ORM is doing and this is what the some of the new ADO.NET 3.0 goo is going to do.
One thing I like so far about what I'm seeing (again, not new to those using ORM, but new to me) is the ability that the Framework gives me to more easily access highly normalized data. Writing t-sql against AdventureWorks, for example, is a huge pain in the butt. I haven't gotten far enough to understand the magic of how some of it is working though. It's one thing to write a simpler query (eg. when you don't have to traverse three tables to gather some key info about a salesperson), but what about the examples where they first say "okay, get the sales people. Now iterate through the salespeople and get their invoices. Now, iterate through the line items and get the sales figures for me." That's not done in one big joined query, but in an OO way. If I wrote that in plain ado.net type code, I would have to hit the database many many times to accomplish something like this. My guess (may be answered by further reading of the whitepaper) is that the framework is analyzing all of the code in advance and then constructing the proper query to hit the database just once.
So, I'm the girl who's too snotty and a bit of a control freak to use DataAdapters. (Although I do know that the new UpdateBatchSize option encourages me to use DataAdapters in some cases now.) I don't like magic. I definitely need to have a better understanding of what's going on underneath before I'll totally buy into it.
I like that there will be more options for data access, but on the other hand, too many options comes with a price and that price is paid by the bulk of developers who don't have to tools or experience to discern the pros & cons of when to use which. We can do standard ado.net data access, we can do drag & drop data access, we can use LinQ over objects, SQL or the Entity Rel Framework (name is too long btw). We can use ESQL against the ERF or we can access it with a new provider (MAP ... MapConnection, MapCommand, etc). That's a lot of options and a lot of new things to learn. We also have new syntax - ESQL, which will be like T-SQL but different (to query the Entity stuff) and the LINQ syntax (aka Yoda speak) which is like TSQL but different and also different than ESQL. These are some of the downsides of ADO.NET being a jack of all trades. I already can predict where the bulk of my run-time errors are going to be -buried in all of this syntax .I have a hard enough time in my kitchen when I refer to the refrigarator as the dishwasher or inadvertently put the milk away in the microwave. Happily, the newer tools will be able to leverage intellisense. There is some "inheritance" that is not really inheritance because, according to the white paper, it will only inherit schema, not behavior. I grok what it's purpose is, but should we have a different name for it? For those who have not been using ORM, this is going to be a big learning curve I think - especially for using it right. I have skimmed over some of the docs and seen there are a lot of layers. (Remember, I am supposed to be on vacation ;-) ).
The ORM folks are pissy (and I can understand, though I'm in no position to judge that one way or another) because they have been forced to fight for a number of years to get Microsoft to acknowledge(?) the value of ORM and now they see Microsoft coming out and saying "oh look what we did".
Either way, I'm grateful for punchier, smarter people than myself who can all help keep each other honest and make the tools great. I'm a little too much of a Pollyanna for that role. I'm impressed with everyone's work and will try to learn it, understand it and explain it to others. It will take a little more real-world use before I have a better idea of what I love and what I don't love.
* mostly vacation, though with three INETA talks in New Brunswick, Nova Scotia and Newfoundland. See my other blog for posts about my travels...