I'm trying to port code from entity framework 6 (EF6) to entity framework core 2.0 (EF-Core) and have ran into a dead end.

In my EF6 code, I have a base class called Record which defines the base properties and methods of all Record types. This base class provides common functionality and properties for all different types of records.

There are many different types of records which derive from the base Record class. Each of these Records have additional properties specific to that type of record. For example, I have a CustomerComplaint class and TrainingRecord class which both derive from the Record class. As you may be able to guess, the two Records have very different properties; however, they both share common functionality such as editing, submitting, permission checking, etc.

My problem is that EF-Core does not support Table per Concrete type inheritance hierarchies (e.g., a separate table for each type of record). Currently, EF-Core only supports mapping inheritance hierarchies to Table per Hierarchy schemes (e.g., a single table with the properties of all subclasses and a discriminator value to differentiate between the subclasses). Given that I have a dozen or so different types of records, a Table per Hierarchy scheme would result in a monstrosity of a table inside my database; it would create a single table with columns for all of the properties of all of my record subclasses!

How should I implement a workaround to this problem? One solution I thought of is to break the hierarchy apart into interfaces and services. I could share common properties by defining an interface with those properties, and I could share common code by moving the code into a service class that operates only on objects that implement my interface.

1 Answer 1


While there of course could be far too many columns in a table, the main reason that this is a problem is when you try to handle all of them at the same time, which would be a problem if you write your own SQL-statements.

Entity Framework is actually quite good at handling Table-Per-Hierarchy, in your code you only see the columns actually used by the specific subclass. Therefore it is not as big a problem as it would be if the sql was written by hand. In your code it will seem as there are a different table for each subclass.

If the table is too big for you, then your own solution sounds good. And would be the way I would go about it.

I haven't tried it, but perhaps you can have each subclass inherit from the same baseclass, but not have a DbSet<> for that baseclass resulting in Entity Framework not using Table-Per-Hierarchy but seperate tables.

  • I tried turning the Record class into an abstract base class and then creating a DbSet<> for the concrete base classes, but EF-Core still turned this into a Table per Hierarchy scheme.
    – Tyler K
    Nov 15, 2017 at 15:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.