Entity Framework derived types support inheritance and relationships, just as you’d expect from any Object Relational Mapper tool (ORM)
Windows Communication Foundation Data Services (Astoria) throws an exception if your derived entities have relationships. That means if a Contact, a Lead, and a Doctor all inherit from a Person… and derived entities have different needs to link to external data… too bad!… Suddenly we have Sales Leads having properties for writing medical prescriptions! Good grief! That’s not going to be pretty… so ugly in fact… we probably don’t even want to go there…. The official prescription for this from the MS forums and various blogs is to move those relationships into the base Person class and then refactor your database storage as necessary…. perhaps having separate and distinct tables for Doctor, Lead, and Contact. Wait-a-sec you say… you picked an ORM because you didn’t want your Object Model to be dictated by your Data Model… well… that’s true… but here you find yourself anyway…
This bit me in the butt big-time on a project I was working on. There was nothing in the documentation and or the services behavior to lead me to believe that this constraint would be present… (well… okay… other than the initials CTP </grin> but still…) Knowledge of the constraint happens way too far along on the development cycle. We did not realize the presence of this constraint until after my team had invested heavily in development of our ORM and database models. These models worked well so long as we were only unit testing them. It wasn’t until we tried to expose them through Astoria that the big bomb dropped in the room.
Having the service tier force a rigid database implementation upon a team is the tail wagging the dog. Also… developer teams often do not have control over what a DBA may require in the database, and WCF Data Services should not be so brittle and constrictive as to disallow common use-case scenarios like practical and real-world use of inheritance. There is nothing complex about this business use-case… in fact I would say it is quite representative of the norm.
My friend Julie Lerman (author of Programming Entity Framework on O’Reilly Press) created a suggestion for this basic “feature” on the Microsoft Connect site. If you agree with its importance… please take a second to click the link and vote on it:
Another item to be aware of regarding inheritance with Entity Framework: two derived types cannot share the same primary key. That means that the a Sales Lead cannot also be a Contact… thus forcing duplication of the Person and all the data related to that person (duplicate addresses, duplicate phone numbers, duplicate emails, etc.). There are no warnings in the designer of this snake in the grass… you’ll know the first time you attempt to retrieve data in the database where these conditions occur (a Person existing in more than one of the derived database tables). You can save the data this way… you can just never retrieve it after the fact! Again… this appears to be a very naïve constraint.