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.
views:
334answers:
2
+2
A:
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.
Craig Stuntz
2009-09-01 19:33:30
Good comments. Inheritance seems more natural here though as it allows me to define relationships between the more specific types.Yes, interesting blog post you link to also - changing an entity to the base type is a form of delete - maybe I shouldn't be doing that at all...
Craig Fisher
2009-09-01 20:53:27
About your added edit: EF does not and can not assume that it is the only process updating the database. In fact in most cases it isn't - you are likely to at least have multiple instances of the ObjectContext operating against the same DB (e.g. one per user in the case of a web app).
Craig Fisher
2009-09-02 15:56:58
I didn't say the EF assumes that it is the only process updating the DB, because that would be wrong. I said that it returns strange error messages when some external process "corrupts" the database. And the EF considers changing the type of an instance a corruption, for very good reasons. This is only an issue if (1) there is an active object context with the object in memory, then (2) some other user "changes the type", then (3) original context does something with the object. The EF will detect the issue and return a highly technical error. Like I said, it isn't multi-user safe to do this.
Craig Stuntz
2009-09-02 16:23:38
So I actually went and tried to model this with what was the subclass as a separate entity with a 0..1:1 relationship to the Employee entity and ran into another EF roadblock. EF won't let you use a primary key column as a foreign key - which is what you normally have with a 1:1 relationship. It basically forces you to create a separate column for the foreign key. Ughh.
Craig Fisher
2009-09-03 16:24:45
It just isn't true that you cannot use a FK as a PK in a table mapped by the EF. We do this many times in our model. Indeed, it's about the *only* way I've found to reliably get the GUI designer to correctly pick up the cardinality of the relationship. I can't say what the problem is without knowing more about it.
Craig Stuntz
2009-09-03 16:55:24
Yes, sometimes it will work, but not always. There are bugs here in EF3.5. I spent ages trying to get the XML right but kept getting spurious validation errors - "Incorrect mapping of composite key columns". Then tried the same XML with EF4 and it works fine. Very frustrating.See http://stackoverflow.com/questions/1337730/delay-loading-expensive-fields-in-entity-framework-v-1
Craig Fisher
2009-09-04 04:57:34
It is true that the GUI designer doesn't understand split table mappings at all in 3.5.
Craig Stuntz
2009-09-04 12:37:52
+2
A:
Technically, you can achieve it by using the stored procedure. TPT does not support it.
However, I totally agree with Craig. In classic programming book Design Patterns (Addison-Wesley Professional), authors discuss inheritance versus composition and conclude that one should "favor composition over inheritance."
Misha N.
2009-09-01 20:33:00
Yes, for now I've implemented this using stored procedures. This was the recommendation from MSFT also:"You cannot do this in the Entity Framework directly. Your best choice would be to write stored procedures for doing these conversions"http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/860d7913-7baa-43e9-a2a7-83b25ad9c558/
Craig Fisher
2009-09-01 20:55:45