What problem is Microsoft trying to solve with all of these data access strategies?

Question

There seems to be many different data access strategies coming out of Microsoft. There’s ‘classic’ ADO.NET, Linq2Sql, ADO.NET Entity Framework, ADO.NET Data Services, ADO.NET Dynamic Data. I’m sure that I’ve missed some. To me, it seems that there’s a lot of confusion surrounding where each frameworks fit into an application's architecture. What problem is Microsoft trying to solve with all of these data access methods?

Answer 1

They are trying to solve the problem of how to increase sales and market share. To that end various groups within Microsoft try to attack the problem of how to get more developers and end-uses using their products. Different groups come up with different technologies and like any big company, Microsoft struggles to keep it's technologies aligned and groups working toward the same end. Additionally, as newer technologies come along they need to keep (or better yet, set) the pace as well as continue to support older technologies that their customers have invested in. The end result for any sort of reasonably large company, including Microsoft, is a somewhat muddled selection of technology selections.

Answer 2

Windows Everywhere

Answer 3

You confusion is our frustration. A lot of us who make these architectury decisions for our websites have thrown our hands up with Microsoft's lack of clarity and good development practices on this issue.

My team certainly got burned by Linq2Sql.

We now build our website with a Domain Driven Design approach and specifically Palermo's Onion Architecture (http://jeffreypalermo.com/blog/the-onion-architecture-part-1/). Business objects are just POCOs and have no dependencies on infrastructure.

The infrastructure is now handled by NHibernate and a custom rolled ORM for our CMS. The painful startup costs for these have been far outweighed by the knowledge that the community will continue to move NHibernate in the best direction and we control the source to our ORM. Worse comes to worse and Microsoft does release something really compelling that works in a DDD architecture, we just need to rewrite our infrastructure layer.

Answer 4

I don't see the point of this question. In fact, it's a bit trollish.

• ADO.NET is the original data access technology from .NET 1.0. It clearly doesn't belong in any discussion of new data access "strategies"
• LINQ to SQL is one of the original LINQ providers. It provides a one-to-one mapping between database structures and the types used in a program. It was meant to work with SQL Server
• ADO.NET Entity Framework is more flexible. It was meant to work with any ADO.NET provider, and has a mapping layer, so that the program works with classes that are closer to being business entities than to database tables. For instance, a single entity may include data from multiple tables. Microsoft has decided to spend more effort on EF than on LINQ to SQL.
• ADO.NET Data Services is a services layer over EF. If you were going to produce your own service to do nothing more than expose your data, then it's a decent bet. It uses a REST interface, and can expose the data in ATOM format.
• ASP.NET Dynamic Data is not a data access strategy. See http://www.asp.net/dynamicdata/.

The distinctions are clear enough that a trivial amount of research would have made them clear.

Answer 5

They have had a data strategy for ages. In fact you can and should search "Microsoft Data Access Strategy" and you will find links old and new (i.e. year 1998 and their OLEDB strategy).

I think what you are looking for is here from year 2007 that even though is 2 years old is about XML, ADO.NET, Data, LINQ, SQL Server, Visual Studio Orcas, Entity Framework...they address the question Does Microsoft have a Data Access Strategy?:

Yes, it turns out we do. Microsoft envisions an Entity Data Platform that enables customers to define a common Entity Data Model across data services and applications. The Entity Data Platform is a multi-release vision, with future versions of reporting tools, replication, data definition, security, etc. all being built around a common Entity Data Model. ...

Mike Pizzo, Architect, Data Programmability

I hope it helps.

Answer 6

I find the article at http://msdn.microsoft.com/en-us/magazine/cc700331.aspx a nice technical introduction to Entity Framework if you're not familiar with the underlying concepts.

Here is a section that is relevant to this question explaining some of EF's goals and relationship to ADO.Net...

The ADO.NET Entity Framework is an evolution of ADO.NET and the first concrete implementation of the EDM, providing a higher level of abstraction when developing against a relational database. In version 1.0, the team has been focused on building up the foundation of a platform, more than just a simple ORM, which will allow developers to work against a conceptual or object model with a very flexible mapping and the ability to accommodate a high degree of divergence from the underlying store.

This high degree of flexibility and divergence from the underlying store is the key to allowing the database and applications to evolve separately. When a change is made in the database schema, the application is insulated from the change by the Entity Framework, and you are often not required to rewrite portions of the application, but rather to simply update the mapping files if necessary to accommodate the change.

To begin evolving the ADO.NET platform, the Entity Framework is built on top of the existing ADO.NET 2.0 provider model, with existing providers being updated slightly to support the new Entity Framework and ADO.NET 3.5 functionality. We chose to implement on top of the existing ADO.NET provider model to ensure a provider model that is familiar to the development community.