Creating Inheritance Relationships in Entity Framework

Far too many developers are under the impression that the business entities that Entity Framework (EF) creates in database-first mode are the business entities you're stuck with: one entity = one table. That's not true; and when you need a more sophisticated design, you can create that.

For instance, imagine a Customers table that contains several different kinds of customers (e.g. "premium" and "ordinary" customers") -- usually flagged by some kind of ‘CustomerType' column. You could create a single class with methods filled with "If…then" statements that check the CustomerType property and run the right code.

Or you could create two classes: a PremiumCustomer entity class with all and only the code/properties that relate to premium customers and a TypicalCustomer entity class with all and only the code/properties that relate to a TypicalCustomer. The code and properties that are common to both sets of customers would stay in a base Customer entity that the other two classes inherit from.

The beauty of EF is that it would manage all the updates made through the three entities back into the single table. If you tell EF about the CustomerType column, it will ensure that the right object is created when retrieving rows in the table, and update the column correctly when you create a new entity.

To implement this design, first let the EF wizard generate your its default entities from your tables. Then right-mouse click on the EF designer and select Add | Entity.  In the resulting dialog, give your new entity a name (e.g., "PremiumCustomer") and specify that it inherits from an existing class (e.g., "Customer") using the Base type dropdown list. You can then cut and paste properties from one class to another (e.g. does the "DiscountRate" only apply to PremiumCustomers? Then select that property in the Customer class, cut it, and paste it into the PremiumCustomer's properties). 

You won't be instantiating the original, base class entity in code anymore, so select it, and in its Properties Window, set its Abstract property to True (i.e. from now on I'll use PremiumCustomer or TypicalCustomer, but not Customer, so I make the Customer entity abstract).

Now you need to tell EF about your type column so it will know when to create the right object. Right-mouse click on one of your new classes (e.g., PremiumCustomer) and select Table Mapping to display the mappings between table columns (on the left) and entity properties (on the right); right now the mapping table will be empty. Click on <Add Table or View> and select your table (e.g., Customers) to tie the table your new entity. Click on the new <Add a Condition> choice and select your type column. In the Value/Property column, enter the data that identifies the row (if it's a string value, make sure you put quotes around the value). Repeat for your other new entities. Finally, delete your type column from your base table -- EF will take of making sure it's set correctly.

And you're done! You now have several classes managing a single table, but the right class will be generated for you at the right time by EF (and, when it adds new rows to your table, it will make sure that your type column is updated correctly). You also have less logic to design because you just have to put the code appropriate for each entity in each of your entities.

Posted by Peter Vogel on 06/21/2012