Should I use inheritance in Entity Framework or is there a better approach?

Question

I have various objects that I would like to track in an application. The objects are computers, cameras, switches, routers etc. I want the various objects to inherit from an object called Device since they will all have some properties in common (i.e. IP Address, MAC Address, etc.) I like to create the objects using the designer (Model First) but I do not like the difficulty in updating the database from the model. Basically, I do not like to have to drop the database and recreate it, especially once I start populating the database. The other approach that I experimented with was creating the database using SSMS in SQL Server, but then when I create the POCOs from the database the entities do not inherit from each other. What is a good approach for my situation ?

Answer 1

I want the various objects to inherit from an object called Device since they will all have some properties in common (i.e. IP Address, MAC Address, etc.)

You are essentially talking about which inheritance pattern you are going to use in EF; or how the model maps to your database tables. There are 3 main types of inheritance patterns in EF (see Inheritance Mapping: A Walkthrough Guide for Beginners):

• Table-per-Hierarchy
• Table-per-Type
• Table-per-Concrete Type

Each has pros and cons (such as performance). But, you should also consider that this model is a model that relates to the database, and in larger projects you might then create a second layer to work with for business logic. DDD talks about persistence models and domain models. Again, your choices here are weighing up initial speed of development and scalability and performance later on.

I like to create the objects using the designer (Model First) but I do not like the difficulty in updating the database from the model.

There are 4, and only 4 development strategies for EF (see Entity Framework Development Workflows):

• Model First
• Code First (new database)
• Database First
• Code-first (existing database)

I do not like to have to drop the database and recreate it, especially once I start populating the database

Code First is really very, very good at this:

• Seeding in Code First allows you to populate databases with test or live data depending on where you are deploying to.
• Migrations allow you to do non-destructive updates to the database, and migrate data in a fully testable, utterly reliable fashion for live deployment.

Doing this with Model First is, unfortunately, just harder. The only real solution I know is to generate a new database, and use a SQL compare (with data compare) tool to generate the data in the new database.

Choosing a pattern and a strategy

Each strategy has pros and cons, and each inheritance pattern is better used with particular development strategies. The trade offs are really your own to judge, for example you might have to use database-first if you have en existing database you inherited, or you may be happier using the EF designer so would use model-first.

Model First (by that I mean using the EF designer to define your model) uses the TPT strategy by default. See EF Designer TPT Inheritance. If you want TPH, then you can use Model-first (see EF Designer TPH Inheritance), but you have extra work to do; Code First is a better fit for TPH. TPC is even harder using Model First, and Code First is really the best (only viable) option for that in EF 5.

when I create the POCOs from the database the entities do not inherit from each other

It is good to remember that the model deals with classes; the database deals with storage in tables. When generating a model from your database it is hard for EF to work out what the TPH or TPC inheritance should be. All it can do is create a "best guess" at your model based on the table assocations. You have to help it out after the model is generated by renaming properties, changing associations or applying inheritance. There really is no other way to do this. Updates to the database may also therefore require more work on the model.

Your best approach

That is, unfortunately, down to opinion. However if your primary requirements are:

1. You want TPH or TPC (or mixed strategies)
2. You don't want to drop your database when you issue updates to the model

then the best match for these technical requirements is Code First development, with migrations and seeding.

The downside of Code First is having to write your own POCOs, and learning the data annotation attributes. However, keep in mind:

• writing POCOs is not so different from writing a database table (and once you are used to it is is just as quick)
• Code First is a lot more usable with automated testing (e.g. with DI and/or IoC to test without the database involved), so can have benefits later on
• If you are going to do a lot of EDMX manipulation with database first, or a lot of work whenever you drop and update your database using model first, then you are just putting in time and effort in other places instead of in writing POCOs