SqlServer 2008: Does it or doesn't it have the Entity Framework?

I just read an interesting post on the Oakleafblog of Roger Jennings. There, Roger enlists his feedback he would have given to the ADO.NET team. It's an interesting list of items, most of them I can agree on. Though the better gems are in the comment posted by Mike Pizzo, ADO.NET's architect.

For example, Roger said:

3. Recommit to Mike Pizzo's fervent promise of RTM with a graphical EDM Designer in the first half of 2008, not "in the Katmai timeframe."

To which Mike replied (emphasis mine):

Orcas, Katmai, and the Entity Framework are all being released as part of a single marketing wave. Apparently we get more when we announce things together, even if they don’t release at the same time. Whatever. Anyway, the Entity Framework has no dependencies on Katmai, and ships as an update to the .NET Framework, not as part of Katmai, so we’re not dependent on Katmai to ship.

Ok, this made me re-read it a couple of times. Did I read it correctly or did I misinterpret it? (probably ).

Another good one is this one:

9. Provide read-only access to foreign key values.


This is actually a feature I’m fighting to get into our final milestone for V1. Can you describe the scenarios where this is used? Do you need the ability to query on the foreign key value, or simply expose it on the domain object?

If I have an Order entity object in memory, if I want to obtain its CustomerID and I only have the ability to get that ID is by fetching the related Customer entity into memory, instead of doing Order.CustomerID, I lose performance which is unnecessary. It's simple data-access stuff and it puzzles me a bit why Mike has to put up a fight to get this into their framework in the first place. Especially since the underlying object context knows that Order.CustomerID as it has to save it to the DB if you change the Customer related to that particular Order instance.

Roger also mentioned this:

2. Provide a similar white paper comparing the projected feature set of EF v1.0 and, perhaps, EF vNext with that of NHibernate, NPersist, and commercial OR/M tools such as LLBLGen Pro, Wilson ORMapper for .NET, et al.

Mike askes for volunteers. Well, as the O/R mapper I've worked on for the past 5 years is on that list, I'm more than willing to help out with that list. . A good starter for which features people might be looking for is this Wiki page over at c2.com.


  • >> 9. Provide read-only access to foreign key values.
    >> [...]
    >> [...] it puzzles me a bit why Mike has to put up a fight to get this into their framework in the first place.

    I bet the reason is one of purity of the Domain Model. "Why do you want to know the ID? You shouldn't want to, it's behind the abstraction and belongs to the DB. All you should care about is that you can access the Customer". Of course, for the reasons you describe, it can be desirable to get to the ID instead of the customer object. That's the danger with DB abstractions. You really can't be completely unaware that your Entity is tied to DB or you are just inviting DB performance headaches.

  • It is not in the SQL server 2008 June CTP

Comments have been disabled for this content.