Changing the type of an (Entity Framework) entity that is part of an inheritance hierarchy

Question

I have an inheritance hierarchy with a base Employee entity and some descendent entities for specific employee types. I need to be able to convert a base Employee entity to a more specific entity (e.g. TemporaryEmployee) and from a more specific type back to the base type (e.g. if an employee is no longer "temporary" then I want that instance to just be persisted as Employee. In the DB this is just a matter of adding or removing a row from the table for the specific subclass. (I'm using table per class.) I'm not seeing how to do this using EF calls though.

Answer 1

One of the tenets of OOP is that instances cannot change their type. Think: Can you do this with ordinary .NET objects? Of course not. You can't do an end run around this hard and fast rule by persisting them with the EF, either.

Adding a row to the DB doesn't change an instance's type, either; it just lies to the EF about what you saved. In the relational domain, you're adding a relation, not changing an object's class, because the relational domain doesn't know about objects.

So the long and the short of this is that using the EF doesn't change the .NET rule that instances cannot change their type.

What should you do when you need to do this, then? Well, think about how this works in your problem domain. An employee is a person. Their employment status is related to the person, but their status is not actually the person.

Use composition instead of inheritance. I would probably model this as Person, with a collection of Employment instances. As a person's employment situation changes, you can assign stop/termination dates to the old records, and add new records for new jobs.

I happened to read this blog post this morning, which may be further food for thought.

Edited to add If you do work around this by implementing a DB stored procedure, make sure nobody is actually using the system at the time when you execute it. Because this is completely illegal in .NET object space, the Entity Framework presumes that it cannot happen. If you circumvent the Entity Framework and do it, and a user happens to have a live ObjectContext at the time, then this ObjectContext will be out of sync with the database in a way that the normal optimistic concurrency protections in the Entity Framework did not detect. You won't corrupt data, but the user with the active ObjectContext may see some incredibly strange errors.