The first announcement made about LINQ made a lot of people hope that maybe the guys in Redmond finally realized the benefits of working with strong, type safe CLR objects. Until then the only data abstraction solution available from MS were the Typed Datasets, which not only are a leaky abstraction and buggy as hell (see this for example) but also have a major disadvantage: is you decide to use them you might as well tie ball and chain to you ankle with “Visual Studio 2005” written on it. Then the technologies that were gonna be using LINQ were announced, like LINQ to SQL (DLINQ back then), LINQ to Datasets, LINQ to Entities, etc. (Maybe it’s just me, but I can’t figure out a single reason to why you’d need two solutions to map your data to your objects. Why isn’t one enough? And no, the argument that you need a simple one and a complex one doesn’t cut it for me.)
Unfortunately a lot of people complained about the complexity of the Entity Framework, it’s dependency to VS, it’s limitations and let’s not forget using no less than 3 XMLs to define the mapping, among which Ayende (here and here ) and Jeffrey Palermo (here).
As a response to all the gathered feedback the ADO.NET Team recently announced on their blog :
We’ve collected great feedback from you in these early releases, the most significant being that we need better tools to aid in defining a data model and mapping that model to the database. Although we have tools for generating a direct mapping to the storage schema, the real power of the ADO.NET Entity Framework comes in its ability to flexibly map a variety of relational schema representations to a more appropriate conceptual application model. This has reinforced the need to have a graphical designer experience available for the ADO.NET Entity Framework.
This is not the kind of reaction I was hoping for 
. Why do I have the feeling that instead of focusing on the simplicity of the framework the ADO.NET team tries to cover it up with a fancy designer?
Sam Gentile wrote about why you would choose the Entity Framework over NHibernate, but I don’t do consulting work, I don’t work for a Fortune 500 company and, to my knowledge, I’m not dumbed down by visual development. As a developer in a small, somewhat independent software company I would not like to be forced to use a framework just because of the brand name.
I’m really hoping that Linq-for-NHibernate will stabilize before Entity Framework’s release. This will certainly make NHibernate much more attractive. Either way, I guess we’ll wait until next year to see what happens. Until then, happy hibernating!
