On a different post I wrote, someone highlighted this comment by Joel Spolsky in one of his blog posts:

Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET - All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That's probably it, actually.) But the end result is just cover fire.

I was a little taken aback, but then went to the original post and realized it was written in January 2002, just as .NET was being introduced. And at that time, I think we were all equally frustrated. I was fortunate to at least have completely skipped learning RDO!

But since then we have watched ADO.NET (the last in his list) evolve, rather than being thrown away for yet another idea. The ensuing versions added more capabilities and improved upon performance, but the core of ADO.NET has remained intact since it's onset.

Even with the introduction of Entity Framework, ADO.NET continues to evolve. EF is an addition to ADO.NET, not a replacement of it. Your existing ADO.NET code and knowledge carries forward. Datasets and DataTables don't go away and it's possible to not only use both technologies in one solution (where one makes more sense than the other) but to push data from one to another (dataReaders are returned from Entity Client and there is also Linq to Dataset, which means you can take a LINQ to Entities query and get the data to a dataview if necessary.

I wonder if (or how) Joel's perception Microsoft's Data Access strategy has changed since he wrote that post nearly six years ago.