Recently, a post by Oren Eini (a.k.a. Ayende Raheim) touched off a debate around the respective merits and capabilities of NHibernate and Entity Framework 4.0, two .NET-based Object/Relational Maping frameworks. InfoQ explored this debate in more detail to understand some of the perspectives which were given.
Sadly the terms “ORM” and “performance problems” often travel together. By hiding the underlying SQL from the developers, ORMs can offer a huge productivity boost. Unfortunately they also make it easy to generate ridiculously bad queries without realizing it. And without stored procedures to cross reference, finding the offending code without an ORM-specific profiler can be quite tricky.
Microsoft’s vision for .NET is a wide one. In addition to support for all programming languages, MS wants to bring together all communication frameworks and data storage engines. While WCF is making headway for standardizing communication APIs, their universal data access model Entity Framework is lagging behind. Much is this is due to lack of direct vendor support from companies like Oracle.
Not everything planned for Visual Studio 2010 made it in beta 1. This includes some important features for ORM fans. Entity Framework CTP 1 includes support for Self Tracking Entities, POCO Templates, and support for EDMX-free coding.
Entity Framework 4.0 Beta 1 – aka EF V2 - delivered with .NET 4.0 Beta 1 contains a list of important improvements: Customization of Code Generation, Lazy Loading, N-tier Support, POCO Support, DDL Generation, Query Customization and others.
Yesterday, Microsoft released .Net RIA Services which was mostly in stealth mode until now. In his presentation at MIX 09, Nikhil Kothari, explained "n-tier development and architecture is hard and un-natural. Our goal is to bring ASP.NET / RAD style productivity to RIA developmend"
OpenLink and Firebird have been added to the list of supporters of the Entity Framework by releasing their ADO.NET 3.5 providers.
IBM has released the production version of its Data Server Provider for .NET including support for Microsoft’s Entity Framework allowing its users to create EDM schemas, and to execute EntitySQL and LINQ statements.
Despite the numerous problems with Microsoft ORMs and the plethora of alternatives such as LLBLGen, nHibernate, and OpenAccess, many developers are forced to use Microsoft tech because that is why their company or customer wants. And between the two offerings, it seems most developers believe that Entity Framework is not a viable option. So what are they do to?
In a recent blog post Stu Smith claimed that “LINQ-to-Entities will return different results depending on what previous queries you’ve executed!”. If true, this would make using Entity Framework much harder than necessary to use. We talked to Elisa Flasko of the ADO.NET Team to find out what’s really going on.
The Entity Framework doesn't support data models with much more than 50 to 100 entities. But since companies typically run everything from one central database, several hundred tables are the norm. Microsoft's ADO.NET team is presenting an article on Working With Large Models In Entity Framework, a list of issues and work-arounds for EF users.
The designers in both LINQ to SQL and ADO.NET Entity Framework have a number of limitations. In order to work around these limitations, products such as Huagati DBML/EDMX Tools have been developed. There is no bloat here, everything is a must have for many shops.
One of the biggest complaints about ADO.NET Entity Framework was that it did not support change tracking. Despite everything from ADO.NET DataSets to every single non-Microsoft ORM having support for this out of the box, Microsoft has no intention of fixing this in the .NET 4.0/VS 2010 timeframe.
Back in July we reported that LINQ to SQL was transferred to the SQL Data Programmability team. This event raised a lot of concern in the developer community, who worried that work on LINQ to SQL would halt in favor of ADO.NET Entity Framework. A recent announcement by Tim Mallalieu, Program Manager of both LINQ to SQL and Entity Framework, has exacerbated those concerns.
More and more, LINQ to SQL is being seen as a temporary solution. With the impending release of ADO.NET Entity Framework, a lot of people are worried that development on LINQ to SQL will fall by the wayside. With Microsoft's long history of developing and discarding database access technologies, these concerns are not without merit. So this raises the question, "Should LINQ to SQL Go Open Source?"