BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations ORM, EDM, ESQL, Entity Framework, LINQ to SQL, LINQ to Entities - Confused?

ORM, EDM, ESQL, Entity Framework, LINQ to SQL, LINQ to Entities - Confused?

Bookmarks
01:02:12

Summary

Eric Nelson explains what are ORM, EDM, and ESQL, what is the difference between LINQ to SQL and LINQ to Entities, which one is going to be further developed by Microsoft in the future, accompanied by hands on demos showing how to use them.

Bio

Eric Nelson has worked at Microsoft UK for twelve years and before joining worked exclusively as a Unix developer writing code in C and other 4GLs. He currently works in Microsoft's partner group and focuses on working with Independent Software Vendors. You can find his blog at: http://blogs.msdn.com/ericnel.

About the conference

QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community. QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.

Recorded at:

Nov 06, 2009

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Microsoft's Track Record...

    by Giorgio Galante,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Microsoft's track record on building a good, solid ORM is horrible. How is it possible that you guys skipped N-Tier support until .NET 4.0? Seriously, there are plenty of cheap, solid ORMs out there (NHibernate, LLBLGen comes to mind to name 2), why reinvent the wheel? Horrible decision making. Having just done a small proof of concept with EF (VS 2008 / 3.5 SP1), I can say that it is light-years behind the competition. Since the upcoming EF is finally getting self-tracking entities...I'm sure they'll be less than ideal (typical for a Microsoft "1.0" of any technology), I guess you might actually get a decent ORM together by..say Visual Studio 2012 / .NET 5.0

  • Still completely confused!

    by Tim Barker,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    After watching this presentation I feel that Microsoft really does not have it in them to do a full blown ORM. On one hand you are trying to push the Entities Framework, but as has been said a few times in this video it only really supports a few scenarios, it has serious constraints in relation to stored procedures, lazy loading, caching and poor Visual Studio support. On the other hand you have a good simple ORM in LINQ to SQL that works well out of the box for a lot of scenarios, has good support in Visual Studio and is much more widely used (and written about) but only supports SQL Server.

    What I would like to see as a user of both NHibernate and LINQ to SQL, is Microsoft to open up the LINQ to SQL provider mechanism so that database vendors can implement support, and Microsoft get over its Not Invented Here syndrome and kill the Entities Framework and put its backing behind NHibernate. It would not hurt Microsoft to pay for development of a plugin to Visual Studio to support NHibernate based development and to perhaps put some money into NHibernates development for it to improve far beyond anything the Entities Framework will ever be.

    The ship has really sailed for the Entities Framework, the release made in .NET 3.5 SP1 was a massive mistake and should have been pushed back until .NET 4.0 so that you could have produced something worth using. Many people today choose LINQ to SQL for simpler projects or where there are more inexperienced developers, or they choose NHibernate (or something that sits on top of) for the more complex scenarios (and in combination with Spring.NET). I just don’t know what the point of the Entities Framework is.

  • Correction, Eric

    by Frans Bouma,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    LLBLGen Pro 3 will support the EF as a target framework but that's not a consession to you, as you made it look like in your presentation :). We'll support EF as the designer is designer to be the designer for _all_ O/R mappers out there, including EF. We still ship our own framework as we think it's better than what EF has to offer, however as EF is freely installed with every vs.net and .NET installation, more and more people will use EF and L2S to a less extend, simply because they're easily available.

    So it's just a business decision, as we've to compete with a free framework supported by MS which is installed on everybody's system. :) Also the reason why we'll also support Linq to Sql and nhibernate. :) I thought I'd clear that up a bit ;).

  • Re: Microsoft's Track Record...

    by Eric Nelson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thankfully you won't have to wait til Visual Studio 2012. Entity Framework 4.0 is a "decent ORM" - not perfect but certainly decent. And yep - our track record (which I lived through) on getting an ORM out the door has been bad.

  • Re: Still completely confused!

    by Eric Nelson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I have a more positive view of where we are Tim. First up, a very small % of .NET projects currently are using an ORM (very small!). And that small % is spread across a number of technologies - NHibernate, L2S, LLBLGen, XPO etc. Each of these technologies has strengths and weaknesses (Honestly they all do - ORMs are hard to get right for all approaches/scenarios).

    EF 4.0 is a decent ORM but it takes a dependency on .NET 4.0. Therefore pre .NET 4.0 there are better choices than EF. However if you can go with .NET 4.0 then I think EF is a very good choice in most but not all cases. At TechEd europe this week the two EF sessions have been very well attended (one full with folks sitting outside). EF 4.0 will be widely adopted and in the main folks will be very happy with it.

  • Re: Correction, Eric

    by Eric Nelson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Frans. I am extremely pleased that we will have alternative designers for EF and that LLBLGen 3 will be one of them as I hear good things about it when I meet with devs using it. I would love to demo it working in my EF sessions as well.
    I certainly wasn't implying that you suddenly felt EF rocked - only that you were indeed making a smart business decision to support an ORM runtime that will likely become very widely adopted.

  • This session in from March 2009

    by Eric Nelson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Just wanted to mention that this is a session from March 2009. The next version of Entity Framework is V4.0 (not v2.0 as I call it in the video) and is currently at Beta 2. You can check out a collection of EF4 resources I pulled together at bit.ly/ef4resources

  • Your message is awaiting moderation. Thank you for participating in the discussion.

    I should state that I haven't looked at EF 4.0 yet (we're waiting for Expression Blend to support VS 2010 .NET 4 projects before moving to 2010), so we've settled on LLBLGen for the moment. At home however, I'm just messing around with EF (still in VS2008/.NET 3.5 SP1) and at minimum, the following "smells" to me:

    Licenses = (from license in db.Licence.Include("SoftwareVersion.Software.SoftwareVendor") where license.Category.Id==CategoryId select license).ToList();

    I have to use a string to specify the 'eager' loading...really? That's terrible, not compile-time checkable, etc.

    I've also noticed in the EDMX's Designer source file where the entities are generated, that no metadata about the underlying storage is made available programmatically. Things like field length, nullable, etc... LLBLGen makes all that information.

    I just can't really see why Microsoft with all its resources, can't provide a more comprehensive solution than a very small company (or NHibernate for that matter) on its 4th (at minimum) attempt.

    I'm not trying to put down EF, or the EF team's efforts... I'm sure you guys will eventually get it right.

  • Re: EF

    by Giorgio Galante,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I've finally had a chance to take EF 4.0 for a spin, and I can say without a doubt, it's still a pile of junk compared to the alternatives. One, the designer is still not up to snuff. Example: Make a FK field nullable, and the designer doesn't pick up (after a schema update) that the relationship should now be a 0...1 instead of 1.

    Two, I'm working SQLCE 3.5 and I'm using identity pk's...which I rudely found out are not supported by EF:

    {System.NotSupportedException: Server-generated keys and server-generated values are not supported by SQL Server Compact.
    at System.Data.SqlServerCe.SqlGen.DmlSqlGenerator.GenerateReturningSql(StringBuilder commandText, DbModificationCommandTree tree, ExpressionTranslator translator, DbExpression returning)
    at System.Data.SqlServerCe.SqlGen.DmlSqlGenerator.GenerateInsertSql(DbInsertCommandTree tree, List`1& parameters, Boolean isLocalProvider)
    at System.Data.SqlServerCe.SqlGen.SqlGenerator.GenerateSql(DbCommandTree tree, List`1& parameters, CommandType& commandType, Boolean isLocalProvider)
    at System.Data.SqlServerCe.SqlCeProviderServices.CreateCommand(DbProviderManifest providerManifest, DbCommandTree commandTree)
    at System.Data.SqlServerCe.SqlCeProviderServices.CreateDbCommandDefinition(DbProviderManifest providerManifest, DbCommandTree commandTree)
    at System.Data.Common.DbProviderServices.CreateCommandDefinition(DbCommandTree commandTree)
    at System.Data.Common.DbProviderServices.CreateCommand(DbCommandTree commandTree)
    at System.Data.Mapping.Update.Internal.UpdateTranslator.CreateCommand(DbModificationCommandTree commandTree)}

    Next: It appears that there's no simple way to set a FK field value on an associated object without re-querying the database. Let me explain - let's say we have an Order entity that has a StatusId FK that references a Status table. I want to simply say order.StatusId=12345 because I know what the right value is. I have not find a way to do this. I've wound up just re-querying the database to get the Status object and assign it to the order.

    Come on Microsoft. How could you guys even release this as a beta 2?

  • Re: EF

    by Justin Spaey,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Giorgio

    "I have to use a string to specify the 'eager' loading...really? That's terrible, not compile-time checkable, etc."
    There's an easy fix for that. See www.codetuning.net/blog/post/Entity-Framework-c...

    "How could you guys even release this as a beta 2?"
    That's why it's called 'beta'

  • Re: EF

    by Giorgio Galante,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I don't doubt that the method provided in that link works (I use something similar for INotifyPropertyChanged raising.) Why didn't they just build-in this ability into EF, instead of adding a lot of useless fluff that no-one asked for?

    As to the 'beta' comment - the overall design and philosophy came from the ivory tower (how else could they explain how they were so off-base in EF v1?) So now they're handcuffed by v1's mistakes...Sure they can make changes, but they won't start over from scratch.

    I'm writing a series of posts on my blog that talks about my main issues with EF (v4 included.) You'll be able to find it at www.giorgiogalante.com.

  • Re: EF

    by Justin Spaey,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Unfortunately, the whole "why are you killing Linq to SQL???" uproar didn't buy Microsoft any points and, understandably, some of the development community feel that there's no reason why Micrsoft won't do the same to Entity Framework somewhere down the road.

    EF v1 is far from perfect and EF v4 probably won't be either, but I feel they are at least going in the right direction. IMHO, the biggest threat to EF at the moment is the amount of time you have to wait between updates. If EF v4 RTM rolls out and receives negative reception, developers arent't going wait until VS 2012 to see if things improve.

  • Re: EF

    by Giorgio Galante,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Even if it's a move in the right direction, people have grown tired of waiting - they already have decent 3rd-party choices available. Why should they switch? Until EF is more polished than the alternatives, it's destined to sit on the shelf.

    Why can't Microsoft just do what it does best, look at what others are doing, copy the best ideas, and then improve it iteratively?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT