Question

I have a situation in which the ideal relationship, I believe, would involve Value Object Inheritance. This is unfortunately not supported in NHibernate so any solution I come up with will be less than perfect.

Let’s say that:

• “Item” entities have a “Location” that can be in one of multiple different formats.
• These formats are completely different with no overlapping fields.
• We will deal with each Location in the format that is provided in the data with no attempt to convert from one format to another.
• Each Item has exactly one Location.
• “SpecialItem” is a subtype of Item, however, that is unique in that it has exactly two Locations.
• “Group” entities aggregate Items.
• “LocationGroup” is as subtype of Group.
• LocationGroup also has a single Location that can be in any of the formats as described above.
• Although I’m interested in Items by Group, I’m also interested in being able to find all items with the same Location, regardless of which group they are in.

I apologize for the number of stipulations listed above, but I’m afraid that simplifying it any further wouldn’t really reflect the difficulties of the situation. Here is how the above could be diagrammed:

Mapping Dilemma Diagram http://www.freeimagehosting.net/uploads/592ad48b1a.jpg

Analyzing the above, I make the following observations:

• I treat Locations polymorphically, referring to the supertype rather than the subtype.
• Logically, Locations should be “Value Objects” rather than entities since it is meaningless to differentiate between two Location objects that have all the same values. Thus equality between Locations should be based on field comparisons, not identifiers. Also, value objects should be immutable and shared references should not be allowed.
• Using NHibernate (or Hibernate) one would typically map value objects using the “component” keyword which would cause the fields of the class to be mapped directly into the database table that represents the containing class. Put another way, there would not be a separate “Locations” table in the database (and Locations would therefore have no identifiers).
• NHibernate (or Hibernate) do not currently support inheritance for value objects.

My choices as I see them are:

1. Ignore the fact that Locations should be value objects and map them as entities. This would take care of the inheritance mapping issues since NHibernate supports entity inheritance. The downside is that I then have to deal with aliasing issues. (Meaning that if multiple objects share a reference to the same Location, then changing values for one object’s Location would cause the location to change for other objects that share the reference to the same Location record.) I want to avoid this if possible. Another downside is that entities are typically compared by their IDs. This would mean that two Location objects would be considered not equal even if the values of all their fields are the same. This would be invalid and unacceptable from the business perspective.
2. Flatten Locations into a single class so that there are no longer inheritance relationships for Locations. This would allow Locations to be treated as value objects which could easily be handled by using “component” mapping in NHibernate. The downside in this case would be that the domain model becomes weaker, more fragile and less maintainable.
3. Do some “creative” mapping in the hbm files in order to force Location fields to be mapped into the containing entities’ tables without using the “component” keyword. This approach is described by Colin Jack here. My situation is more complicated than the one he describes due to the fact that SpecialItem has a second Location and the fact that a different entity, LocatedGroup, also has Locations. I could probably get it to work, but the mappings would be non-intuitive and therefore hard to understand and maintain by other developers in the future. Also, I suspect that these tricky mappings would likely not be possible using Fluent NHibernate so I would use the advantages of using that tool, at least in that situation.

Surely others out there have run into similar situations. I’m hoping someone who has “been there, done that” can share some wisdom. 🙂

So here’s the question… Which approach should be preferred in this situation? Why? Is there a better option that I haven’t considered?

Answer 1

Just a few observations / questions…

• if the different location formats have no overlapping fields, what is the commonality in them which would make them candidates for a subclass hierarchy? Can you actually define a common interface for the base class Location?
• is a TypeALocation comparable with a TypeBLocation?
• are the two locations in SpecialItem of the same type, or can they be mixed?
• can an item change its location to a different type runtime?

As you state above, value objects can’t be polymorphic. Based on what you describe, I don’t see how can you treat locations polymorphically.

Update If you can’t define a common base interface for your location types, it is very awkward to try and treat them polymorphically, regardless of whether there is ORM or not. Taking your example below, even for accessing any information about the actual location I live, you needed to downcast it to either a street address or a lat/long coordinate. Polimorphism is meant exactly to avoid the need for such downcasts (and switches on type fields, etc.)!

Looking at the options you describe above, with all this taken into account:

1. Just as you, I don’t like it either (hardly suprising).
2. Can be a viable option if there aren’t many location types and you can be reasonably sure that you have implemented all the types ever needed. In this case the domain class would practically be the analog of a C union, with a type field. It is a bit awkward to use, but the polymorphic attempt would be even more awkward IMHO.
3. It is definitely an interesting idea which I will probably experiment with in a pet project sometime, but I am not quite sure I would like such tricks in my production code. I guess it could also be done with a custom mapping type which would map your component to a specific subclass. But then again, we’re back trying to fit these incompatible types into a type hierarchy… the only good reason to try this path is if there are many location types and/or new types may appear in the future.