4. Complex Models

So far we’ve looked at how Entity Framework addresses the impedance mismatch problem, the way the Entity Model Wizard creates and updates a model based on a database schema (which, you’ll recall, is only one way to do it), and the tools the Entity Framework Designer provides for tweaking the conceptual model and how the conceptual entities map to objects in the database.

What we haven’t done is make any architectural changes to the conceptual model the wizard created. (Changing a name or deleting an entity here or there doesn’t count.) All of our entities have mapped directly to individual tables in the database. In practice, that will actually be true most of the time. Well, some of the time. Okay. It’s true occasionally. It’s just as likely that a database schema that’s been normalized by decomposition or optimized with one-to-one relationships would be more naturally represented in an object model using composition or inheritance.

That’s what we’ll explore in this chapter. We’ll start by looking at a few ways to split, combine, or chunk data in your entities, and then we’ll explore the two types of inheritance that are supported in Entity Model Designer: Table-Per-Type (“TPT”) inheritance, in which the properties that extend inherited types are stored in separate tables, and Table-Per-Hierarchy (“TPH”) inheritance, in which a single table stores both parent and child types, with a field indicating what type the row represents.