Provider availability enables Entity Framework and Data Services over many database vendors

There are fresh news about ADO.NET provider support here, and there is an official looking statement from last December with more details here.

The ADO.NET Entity Framework is designed so that the upper layers of the system are database-independent. There has been many attempts at this in the past, with varying degrees of success.

I really like the Entity Framework approach because it goes all the way. It's not just a bunch of interfaces to make the API itself generic, but it's also machinery to make things that need to be provider independent so. For example, the Entity SQL compiler and the LINQ to Entities translator sit high in the stack and provides the *same code* for query translation across all databases. That means guaranteed consistency in syntax, something that was somewhere between hard and impossible before.

Of course, at some point we hand out the query expression to the provider for database-specific handling, and behavioral differences may arise there, but they are much more contained.

Coming back to the topic at hand, I've been looking at all the buzz about adoption of the ADO.NET Entity Framework provider model and how it enables access to many databases. This is a big deal...we kind of slowed down on database independence with previous versions of ADO.NET. This new round restores the database independent capabilities.

This is great news both for the Entity Framework and for Data Services (Astoria). It means that developers writing middle-tier code against databases and those creating Data Services get immediate support for using many databases in addition to SQL Server.

In the case of Data Services, the system itself is designed for data source independent beyond databases. If you have an IQueryable implementation, you're ready to go for read-only services (and you can add IUpdatable for update support). For custom data sources this flexibility is great. However, when you're targeting relational databases there is no need to go through the process of writing your own IQueryable (which is far from an easy task); we included rich database support out of the box through integration with the Entity Framework.

-pablo