Vendors Line Up Behind ADO.NET Entity Framework

Posted by Jonathan Allen on Dec 20, 2007 06:46 AM

Community

.NET

Topics

Data Access

Tags

ADO.NET ,

LINQ

ADO.NET Entity Framework represents the first major data modeling endeavor from Microsoft since the inception of the .NET framework and typed datasets. Essentially, it serves as an intermediate layer between application code and the database. It is different from LINQ to SQL in that it does not closely mirror the underlying database structure. Instead, data objects are modeled directly and the mappings are handled in an after-the-fact fashion.

At first, Microsoft will only be including the SQL Server provider LINQ to SQL. However, the other database vendors are not going to allow themselves to be left behind. Eight vendors have announced that they will have providers within three months of RTM. David Sceppa of ADO.NET posted this list.

• Core Lab - Providing connectivity to Oracle, MySQL, PostgreSQL and SQLite databases
• IBM - Providing connectivity to both IBM DB2 data server and Informix Dynamic Server (IDS) databases
• MySQL AB - Providing connectivity to MySQL databases
• Npgsql - Providing connectivity to PostgreSQL database versions 7.3+ and 8.x
• OpenLink Software - Providing connectivity to Oracle, Informix, Ingres, Sybase, MySQL, PostgreSQL, DB2, Progress and Microsoft SQL Server databases, and any data source accessible via OpenLink ODBC or JDBC bridge drivers
• Phoenix Software International - Providing connectivity to SQLite databases
• Sybase - Providing connectivity to SQL Anywhere databases
• VistaDB Software - Providing connectivity to VistaDB databases

1. Back to top

   Minor corrections....

   Dec 20, 2007 10:05 AM by Clinton Begin

   >> ADO.NET Entity Framework represents the first major data modeling endeavor I wouldn't call it a "data modeling endeavor". It's more of a data mapping and concept modeling solution. The conceptual model is mapped to the data model, and the application is subsequently mapped to the conceptual model -- if necessary. Often the conceptual model itself is a reasonably good representation of the domain of the application and can therefore be used directly either with classes generated by the tools, or using anonymous types. >> Microsoft will only be including the SQL Server provider LINQ to SQL LINQ to SQL will remain separate and independent of entities. The LINQ provider for entities is appropriately named LINQ to Entities. What makes me sad about entities is that it reminds me a lot of EJB 1 and 2. The implementation will likely be far better and hopefully simpler. But the idea is the same (although explained more clearly). Look forward to similar patterns and anti-patterns (DTO, business delegate, extra layering) to deal with the same limitations and design constraints that Java developers lived through during the good ol' Enterprise Java Bean days... Clinton

   Reply

2. Back to top

   Re: Minor corrections....

   Dec 20, 2007 10:08 AM by Clinton Begin

   Oh.... and to draw even more parallels to EJB, Entities comes with its very own proprietary query language, just like good ol' EJB QL... "Entity SQL" Party like it's 1999... :-)

   Reply

3. Back to top

   Oracle itself doesn't support it

   Dec 20, 2007 11:29 AM by Frans Bouma

   The snippet in the RSS feed suggests that Oracle lines up behind the EF as well. But that's not the case, at least not for now. It's unclear when or if they'll release an ODP.NET for EF

   Reply

4. Back to top

   Re: Oracle itself doesn't support it

   Dec 20, 2007 11:44 AM by Jonathan Allen

   My apologies, I will alter the summary to be clearer.

   Reply

5. Back to top

   I agree.

   Dec 20, 2007 1:00 PM by Francois Ward

   A lot of the recent stuff that came out in .NET 3.5 is from people wanting to do things the "good old way", regardless of how good or bad these things are. ASP.NET MVC, Entity Framework, the list goes on. Personally, I liked the concept of Datasets. It isn't very mature, and right now I don't use them, they don't do exactly what I want, but with a couple of significant upgrades (like many parts of the framework got), it could be the perfect data handling mechanism, fixing issues Java developers were fighting even before .NET came out (and are still fighting with). But people were so stuck in their mindset, that they begged to get the same old object based mechanism that ripple all over the place as soon as the model changes. Microsoft had little choice but to deliver, even if in the long run, it will hurt more than help...

   Reply

• Older >