"The Entity Data Model is much bigger than just an ORM" -- Stephen Forte

With almost bleeding ears I'm currently listening to show #369 of .NET Rocks!, which has Danny Simmons and Stephen Forte as guests. Danny is of course known of his major role in the Entity Framework (EF) design and Forte is one of the Council of Wise Men (TM) which are advising the EF team how to make the EF a better product / system / whatever.

The quote in the title is one of many silly remarks you'll encounter while listening to the show. Let me start by the quote in the title of this post:

"The Entity Data Model is much bigger than just an ORM". -- Stephen Forte

Now, I know a thing or two about O/R mapping, O/R mapping tools and the like, but for the life of me, I can't understand what mr. Forte means with the above quote. I mean: the EF allows you to define entities, map them to a elements in a persistent storage, generate code from that to use these defined entities in your code and... that's it. If the Entity Data Model is so much bigger than an O/R mapper (ORM) (is that even possible? Isn't that comparing a model (declarations) with a toolkit (code) ?), what else is there that I apparently must have missed? Ok, so you can use the model defined in the edmx file with other toolkits, big deal, I can do that in LLBLGen Pro as well: the whole model is available to you in an object graph which is accessable through any task performer class so you can use it for whatever you want: emitting code, do configurations, creating other projects, whatever comes into your imagination.

The two discuss this feature of the EF as if it's an achievement of the EF, but that's not true: it's the achievement of the consuming tools like Astoria and Dynamic Data, that they can use an edmx file and the embedded model for their own services: any O/R mapper which has a designer which lets you define a model and mappings has the same potential and the same feature, the only thing that isn't there is that the EF is from Microsoft and Microsoft also produces the services which seem to work fine with the EF. If Microsoft puts in the effort to make their tools drag-n-drop compatible with other O/R mappers out there, the EF would look like the tool it actually is: Yet Another O/R Mapper, one with one of the most crappiest model designers ever made. I mean, if the EF is meant for serious applications bigger than the average Mickey Mouse website app, why is the EF shipping with a designer which forces you to have everything on one big canvas?

What's on the table with the EF, what's available to the developer, is simply an O/R mapper: it defines an abstraction above the tables/views in the database, though any O/R mapper is doing that. That's the sole purpose of an O/R mapper!

Sorry Danny and Microsoft, you can keep on trying to sell the EF as something much much bigger than an O/R mapper framework, but it won't help: walk, quack, duck etc.. What strikes me as silly as well is that Microsoft tries so hard to make it not look like an O/R mapper framework, as if O/R mappers are bad and evil. "*Boooohh*, beware of the evil ORM! Quick, call EFMan to rescue us!"...

After speaking out the quote in the title, Forte seems to step on a block of soap as he slips into bezerk mode with the all time classic:

"You can even build ORMs on top of the Entity Data Model" -- Stephen Forte

He then goes on to refer to Ideablade for already doing this. Sorry Stephen, but Ideablade's $2500 per seat (!) costing product isn't an O/R mapper. It's effectively an additional framework with features not a lot of people will ever need on top of the EF, using the EF as... its O/R mapper! He ends with the wish that the NHibernate developers would rip out the, and I quote: "Old Code", and instead build on top of the Entity Data Model. No I'm not making this up.

Why would Ayende and friends do that? What advantage does it have for the user, the application developer, that NHibernate would replace their O/R mapper logic with the EF? That would be a step backwards: all the flaws in the EF are then suddenly something you've to live with and changing things in the O/R mapper core by the NHibernate team is hard because... they don't own the code, it's closed for them. Similar to us: we won't replace our own O/R mapper framework with the EF, because that would mean we've to drop features like auditing, authorization, entity views, advanced eager loading etc. etc. Porting some of that to the EF would make sense, to help out the ones who have to work with the EF because some CTO thought it would be wise to base everything on the EF. But replacing the O/R mapper logic with the EF makes no sense whatsoever. The outspoken wish coming from Forte shows to me clearly that Microsoft is struggling getting major support for its second O/R mapper framework.

With that latest remark, Forte makes his "EDM is much bigger than just an ORM" statement even more difficult to understand: if the EF can serve as the base for an O/R mapper, how can it be, and I quote: "much bigger", than an O/R mapper? I think I must have missed something plainly obvious everyone else is apparently seamlessly understanding. However, if a person like me who has spend almost every minute of the past 6 years on O/R mapper framework design and development doesn't understand what's so incredibly special about the EF, how is Microsoft thinking about convincing the developers out there who have spend perhaps a month of their life fiddling a bit with O/R mappers or not at all, that the EF is the Silver Bullet for everything Data Access?

Here's how, and Forte says it himself: "Push it as a platform". But, it's not a platform, it's an O/R mapper framework to work with data somewhere in a database. Windows is a platform, .NET is a platform, the EF isn't. Positioning it as a platform will pollute the minds of the novices that the EF will do much more than it really does, what it really is. I mean: the list of features Danny mentions at the end as features for 'v2', those are features often already found for years in major O/R mapper frameworks out there. If EF is a platform, or in the light of Microsoft's 'vision': the platform, for data-access, what are those O/R mapper frameworks which pack even more features which the EF clearly lacks at the moment? Super-platforms? Oh no, my mistake, those will of course still be 'just ORM's!

I don't mind yet another O/R mapper framework on the market, even if it's from Microsoft: the more frameworks, the more people get interested in O/R mapping. What I do mind is that Microsoft tries to sell the idea that before the EF there wasn't any data-access framework out there which could do what the EF does, combined with a bundled release of the EF inside SP1 so every developer gets it installed by default. But I guess 'fairness' isn't something you should expect in business-land, so it's a given that this would happen eventually.

The solution to it is of course to cope with it and to come with an answer which will make Microsoft's effort look like a pig with lipstick. Oh, and without the help of a Council of Wise Men. Because you know, it doesn't take a Council of Wise Men to create what you should be creating: you should create what you personally would like to use, what you as the architect and developer of the framework would like to see in that framework because if that given feature wasn't there, you wouldn't use such a framework yourself. One doesn't need a Council of Wise Men nor a petition of angry ALT.NET-ers to get things in the right direction: just build it for yourself. That does require that writing such a framework can only succeed if you have written the alternatives by hand yourself already a couple of times. As Microsoft has done that a gazillion times internally (Sharepoint, CRM etc.) one can't deny that there is a group of people inside Microsoft who know what is needed and what isn't: for example, who cares if the EF isn't POCO, does anyone out there really think that the people who are now in love with NHibernate will jump ship to the EF and embrace it? Why? Yegge is absolutely right in his post linked above. That's not to say you shouldn't build in features you wouldn't use yourself, of course you should. But chances are the set of features you've to build which aren't used by yourself is pretty small.

To me, it's a big failure to surpass these internal group of people who already know what to build and instead hire a group of Wise Men, who individually likely know what they're talking about in their own field and playground, but are so far away from the developer who has to use the framework created. I'm sure the Council will produce a solid, clear vision. I'm also pretty sure that vision is shared among a lot of 'architects' across the globe. But above all, I'm sure the Council's vision is not what the EF needs. What's even more troubling is that apparently the EF team doesn't have a strong vision themselves what to build. How can that ever lead to a framework which does what it should do? Scott Ambler wrote his design documents almost a decade ago. Toplink (now open source) is more than 10 years old and often considered one of the best O/R mapper frameworks ever made. It's not as if the problems the EF team is trying to solve are new nor that the solutions for these problems have been crappy at best, on the contrary. If after all these years, after all those solutions, effort, papers and debates, the EF team still needs external counseling, they need something else: an internet connection and a pair of glasses.


  • I used to fear that Solutions Design would get purchased by Microsoft and LLBLGenPro would disappear. Nothing to worry about now...

  • 'Stealth' marketing & PR by Microsoft?

    Nothing new really...

  • I don't see what all the fuss is about. If you the product is no good, don't use it. Microsoft don't have a monopoly on ORM software. I'm sitting back reading all the bickering back and forth and I think a lot of time is being wasted here. This is a v1 product, so I'm sure there will be inprovements in the next version.

  • @dan: sour grapes? Look, I wouldn't care about the EF if MS didn't put a major effort in telling everyone and his brother that the EF is the only reasonable o/r mapper / dataaccess framework out there worth using and ... it's on everyone's machine already.

    If this is such a great framework and BETTER than all the major mature frameworks out there (which most of the time are available for over 5 years already), why is the focus of the team writing the code apparently so blurred?

    So in a sense it's a remark against the FUD coming from MS regarding O/R mapping and data-access in .NET.

    If you think I have nothing to contribute, please do realize that the EF team did among others use my work in user studies how to build their EF. I think I have a lot to contribute to them, I'm one of the small group of people who has written a mature, very successful O/R mapper system with more features than their multi-million dollar project. The question is: why should I help them if their goal is to make all data-access flow through their work so effectively make it impossible to make a living out of building tools for data-access on .NET.

    As I said: the answer is to cope with it and proof their offering isn't what they say it is. I will, and sooner than they'll come with v2.

  • @dan: Frans expresses himself in a more ...european... way than most americans and brits are used to. To those who are not used to this more straight-to-the-point way of communicating maybe it comes across as bitterness or sour grapes.

    Trying to use less harsh words than Frans, I have to agree that EF version 1 is not quite ready for production use in anything but small-scale/experimental/limited-usage systems. I think EF was simply pushed out the door prematurely because MSFT _had_ to release SP1 for Visual Studio due to the SQL Server 2008 release and bad internal coordination. Once they realized that VSSP1 had to be released hand-in-hand with SQL 2008, they couldn't start breaking out features from both VSSP1 and .net 3.5 SP1 with such short notice. (for technical, marketing, and "face saving" reasons)

    Instead [I think] they decided to ship EF and some other things that had not gone through all cycles of testing, bug-fixing and refinement.

    I have great hopes for version two or three and keep posting my opinions on the matter in the EF forums:

    On a side note, Linq-to-SQL that shipped with VS2008 RTM is a far better OR mapper than EF in its' current state, although the L2S designer leaves a lot to be desired too. Besides the L2S designer leaving features to be wished for, I have used it as the OR mapper in a medium sized system developed from scratch and I am extremely happy with L2S. I just _hope_ that MSFT will continue supporting L2S and add features to the L2S designer instead of neglecting it as they did for SP1.

    I'm still experimenting with EF hoping that I just have to learn to navigate around the version one shortcomings. However, I have a gut feeling that in a week or two I will be back to using L2S instead of EF. At least until the next version (the "real" RTM) of EF.


  • Why don't you go on .NET Rocks and talk about your perspective? I would love to hear your side as well (notice I said "hear" not "read" :D)

  • @dan: Next week when you release your perfect development tool called, my glass house v1.0. and sell a million copies, because its that good.  What will your opinion be when Microsoft comes along and does the same thing for free, with less features?

    I guess everyone is so use to Marketing lies they don't care anymore when it happens.

  • Frans: I think you do have something very valuable to contribute but that it is not evident in this post or in some of the recent ones I've read. Microsoft typically gets slammed for being closed and monolithic, but now that they're being open and agile, people aren't happy with that either. As a developer, I want to see them keep reaching out to the community like they've done in EF and in MVC.

  • @dan: I think the 'openness' is a one way street, even though it looks like it's not. MS' development process isn't driven by community input, a lot of people out there wished it was.

  • @pbz: if Carl and Richard want me on the show again, sure! :)

  • I'm glad I'm not the only one that found that statement a little annoying - "The Entity Data Model is much bigger than just an ORM" - that's great 'n all, now tell us what this grand design encapsulating ORM in just one tiny corner _IS_ exactly... if Microsoft is going to be more open, why not share this larger picture with us now?

    It does seem a bit like scare tactics (almost) - kind of a "trust us, you want to be in on this... things are going to get so much better" statement - without any follow up, how am I supposed to make an informed decision based on a promise... if I start a green fields product using NHibernate now, am I going to miss out on an opportunity to stitch myself into the grand design they're weaving?

    I suspect there really is just some obfuscation going on here, and it will turn out that compatibility/compliance to the meta data standards is all that's really important, and EF isn't really a true (or certainly required) part of the grand design at all - but that's hardly a good message to "send" out (at least when only just introducing EF to market) I guess I'll wait and see what comes of future versions of the EF, for now there's certainly not much compelling reason to move off an existing proven ORM platform.... of course I could be wrong, I don't know what they're cooking up in the labs, which I guess is the root of the problem :)

  • I'll stick with NHibernate... It works, and works quite well.

    EF sounds like it has it's typical MS 'Version 1' stigma - I'll wait to see what EFv2 brings.

    NHibernate.Linq is a good option ;)

  • In the past I have been critical of the "critical" opinions regarding EDM, however after using the tool in a project (and now backing away from it...rather quickly) I see it as a flawed product.

    First and foremost, it doesn't offer any features that Linq To SQL does: in fact it's a step back since the toolset does not work correctly. For example, try doing an "Update Model from Database" after modifying anything in the editor...everything breaks and it is very difficult to fix what has broken; the best/easiest solution is deleting the whole *.edmx file and starting over.

    Secondly, it doesn't offer near the features of established, mature ORMs like NHibernate or LLBGEN. It's like they are offering a BMW, but providing a YUGO.

    Lastly, I hate the fact that I cannot map to POCO classes...I don't want the auto gen'd wrappers it creates.

  • First, let's keep in mind that some people make technology decisions that are Enterprise-wide and not just application or project specific. If I purchase software from Microsoft, this might be of interest to me as a corporate consumer.

    Now, we need to remember that this is just the first release of EF and the long-term vision could change it into something totally different. If EF is actually going to become something that is leveraged by other Microsoft products (System Center, Biztalk, etc.), then we need to take that into consideratoin and understand the business reasons for doing so.

    For instance, it doesn't make sense for Microsoft from a licensing perspective to package up nHibernate in a server product and ship it, does it?

    I think we need to listen, very carefully, to what Microsoft is saying about the EF and maybe think a little bit like a product company in order to better understand their message. Then, as an industry, we need to challenge the current product and vision to see where it shines and where it falls down and provide some constructive feedback. If we don't like it, don't use it. If we see some merit, let's bring that up as well and point out where it's lacking.

    I can't tell you how annoying it is to read comments by individuals that simply say "I played with it for a few days and it sucks" without providing some constructive information as to what judgement criteria was used in the analysis and how the features actually fared in the test.

    Clearly, EF, in its current incarnation, is not nHibernate. However, given that the largest software company in the world is now finally getting around to ORM and the modeling of Enterprise-wide data for consumption by both home-grown and shrink-wrapped software feels to me like a good thing. What's important is that we encourage the extensibility story and figure out how to play nice with each other in order to continue to provide choice. Perhaps nHibernate will outlive its usefulness and perhaps it will evolve into some complementary technology to EF and vice versa.

Comments have been disabled for this content.