I was looking for a reference in ADO.NET Entity Framework documentation (via Google) if a Complex type in an EDM could be part of an association (relationship) like Hibernate supports. I needed this for some tool I'm working on 
. Google gave me an interesting link, namely to a patent held by MS about relationshipsets in the EDM. It refers to other patents of similar straight-forward concepts, either based on stuff defined by Codd or defined by other O/R mapper frameworks like Hibernate or Toplink long before the filing took place. Why these common concepts are even patentable (as they're discoveries in math-space, so not really inventions) is beyond me.
I think it's great that people get credited for their work, after all they put in the hard effort. The problem with these kind of patents like the example above, is that unless you patent the living daylights out of every line of code and every design you think of (which costs a lot of money), you'll sooner or later find that some company owns a patent of work you perhaps thought of first but you don't file a thousands of dollars costing patent request for every design, so someone else filed a patent.
This is a big risk for software engineers out there. I know Microsoft in general doesn't use patents to bitch on competitors or companies who make stuff they also make. But some other company, e.g. a patent-trolling lawfirm who bought a stack of patents, might. It's good the EU forbid software patents for now and it's likely they'll never be valid here. Let's hope the US patent office is following suit.
Btw, 'Object relational mapping' is patented a lot of different times, often duplicates more or less. Oh, and the answer to my initial question is: no, complex types can't refer to entity types. (Which is expected, having a reference to an entity from a complex type (Value object in DDD) seems rather strange and a true edge case)
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.