With Entity Framework 4 (EF4), when we are defining our Entity data model (EDM) we can make use of inheritance and abstract classes rather than the simple mapping that you get when using the DBML designer we get with LINQ-SQL.  However, it is not without its limitations…

Base Class without an Entity Key

The scenario for this one is that you want to use an abstract base class that contains some common properties you use throughout your model in your various entities, for example audit related properties. So we might try to define the following:

However, we instantly have a problem: you will get error 159 stating that the base class has no key defined, and telling you to define one.  Also, due to the defined inheritance our two child classes that had Id marked as their Entity Keys are now marked as False and disabled:

Now there is a way around this that Zeeshan Hirani shows in his book and on his blog:

How to share common fields between two entities that map to different tables

Basically it involves created an Entity Key in the abstract base and then editing the XML to map the child Ids to the base Id and removing the bases entity set.  Also, as it’s likely that the child Ids could conflict (e.g. both be 1!), then we need to create an entity set for each.  And this means using Multiple Entity Sets Per Type (MEST).

However, before you get too excited you should know that MEST is not supported in the current designer…and when I say ‘not supported’ I mean once you use MEST, you will not be able to use the designer anymore on that particular model.

So if you proceed with this approach, you may decide to live without the designer OR you could keep such designer breaking changes separate and import them (I think the latter makes more sense?!).

However, in our scenario you can see we have a problem before we even roll up our sleeves: Our child Entity Keys are of different types.  I would suggest that when using an existing database schema, it is more than likely that you will have a number of different primary key types.

Generics spring to mind, but at the moment I don’t think that’s a viable option? (Please tell me it is and how someone?!)  Current type choices are:

In the end I took a step back with this particular issue, and decided to create a Complex Type for the audit information:

Not only does this deal with the issue of avoiding property redundancy, but it actually provides more scope when we have different depths of inheritance where each entity in the hierarchy maps to a table, e.g. Contact->Student…we can have an audit property on both if we wish and still inherit Student from Contact (as long as you name the audit property differently to keep both copies of audit information!).

From what I’ve heard, using Complex Types used to be a lot harder in the previous version.  Creating new ones is now very easy: we can simply select our properties, right click and pick to “Refactor into New Complex Type”:

That’s great! Fantastic! Thanks guys!

However, what about the subsequent 100 times we need to “Refactor into Existing Complex Type”?! Seems to be an optional extra that’s missing from my designer ;-) (Yes, I know…developers are never happy…always wanting more…)

Anyway, I digress. Next post we will take a look at issues around table-per-type (TPT) inheritance when working from an existing database schema.