Entity Framework 7 (EF7) Preview 5 has shipped with support for Table-per-Concrete type (TPC) mapping. This blog post will focus on TPC. There are several other enhancements included in Preview 5, such as:<\/p>\n
Read the full list of EF7 Preview 5 enhancements<\/a>.<\/p>\n By default, EF Core maps an inheritance hierarchy of .NET types to a single database table. This is known as the table-per-hierarchy (TPH) mapping strategy. EF Core 5.0 introduced the table-per-type (TPT) strategy, which supports mapping each .NET type to a different database table. In EF Core 7.0 preview 5.0, we are excited to introduce the table-per-concrete-type (TPC) strategy. TPC also maps .NET types to different tables, but in a way that addresses some common performance issues with the TPT strategy.<\/p>\n In this post, we’ll start by describing the structure of TPH, TPT, and TPC mappings, then look at how these strategies can be configured in EF Core, and finally discuss the pros and cons of each approach.<\/p>\n Consider the following object-oriented domain model:<\/p>\n If we are to retrieve some Further, different information is associated with each Inheritance mapping strategies (TPH, TPT, or TPC) define how this object-oriented type information and type-specific information are saved into a relational database, where inheritance is not a natural concept.<\/p>\n With the TPH strategy, a single table is created for all types in the hierarchy–hence the name “table-per-hierarchy”. This table contains a special column containing a “discriminator value”, which indicates the type of the object saved in each row. In addition, a column is created for every property of every type in the hierarchy. For example:<\/p>\n Saving two cats, a dog, and a sheep to this table results in the following:<\/p>\nTable-per-concrete-type (TPC) mapping<\/h2>\n
Mapping inheritance hierarchies<\/h3>\n
public abstract class Animal\r\n{\r\n public int Id { get; set; }\r\n public string Species { get; set; }\r\n}\r\n\r\npublic class FarmAnimal : Animal\r\n{\r\n public decimal Value { get; set; }\r\n}\r\n\r\npublic class Pet : Animal\r\n{\r\n public string Name { get; set; }\r\n}\r\n\r\npublic class Cat : Pet\r\n{\r\n public string EducationLevel { get; set; }\r\n}\r\n\r\npublic class Dog : Pet\r\n{\r\n public string FavoriteToy { get; set; }\r\n}<\/code><\/pre>\nAnimal<\/code> object from the database, then we must know which type of animal it is. We don’t want to save a cat and then read it back as a dog, or vice versa. (I can tell you from experience that dogs generally don’t like to be treated as cats, and cats certainly<\/em> don’t like to be treated as dogs!) So this means the type of animal–that is the actual class used when the animal was created in C#–must be saved to the database in some form.<\/p>\nAnimal<\/code> object depending on its type. For example, in our model, a farm animal has some monetary value but no name, while pets are priceless and named.<\/p>\nThe TPH strategy<\/h4>\n
CREATE TABLE [Animals] (\r\n [Id] int NOT NULL IDENTITY,\r\n [Species] nvarchar(max) NOT NULL,\r\n [Discriminator] nvarchar(max) NOT NULL,\r\n [Value] decimal(18,2) NULL,\r\n [Name] nvarchar(max) NULL,\r\n [EducationLevel] nvarchar(max) NULL,\r\n [FavoriteToy] nvarchar(max) NULL,\r\n CONSTRAINT [PK_Animals] PRIMARY KEY ([Id])\r\n);<\/code><\/pre>\n