Entity vs Value Types in Hibernate
One interesting pattern in Hibernate is the distinction between Entity and Value object types . . .
Let's say (as per the example in the excellent Java Persistence with Hibernate - the second edition of "Hibernate in Action") that you have a system where a User may have an Address. If two Users enter exactly the same Address, will both point to the same instance of an Address object in a separate table with a distinct identity (an Address Entity) or will both just have the same information, but stored independently - perhaps in the User table (an Address Value object)?
The power of the idea of Value objects is that it allows for the development of a fine grained object model where you will often have multiple objects per record in a database table (an Order record might have the Order, a composed BillingAddress, a composed Shipping Address, a composed Payment, etc.).
I'm trying to decide whether or not to support the attributes required to describe value objects in my meta-model. On the one hand it allows for very rich object models. On the other hand it adds a degree of complexity to the system. Although as I think about it, the defining complexity is just that changes to a value object rely on knowing the object type and identity of the object they are within. If you want to edit BillingAddress for Order 73, I just need to know BillingAddress is a value object within an Order (which gives me the db tale to use) and that the identity is based on (say) OrderID = 73, giving me the row to update.
It becomes a little more complex generically generating the forms and processing scripts as they need to be smart enough to know to loop through the properties of composed value objects when generating displays and the like, and you'd probably have to provide a direct proxy mechanism so if you wanted to list Order.TotalPrice and Order.BillingAddress.City for a list of Orders you'd probably want to be able to just display using Order.getTotalPrice() and Order.getBillingAddressCity(), saving the extra object creation that would be required for an Order.getBillingAddress.getCity() style interface.
Definitely interesting stuff. Anyone out there using value objects extensively to make their object model more fine grained? If so, how are you handling persistence (I don't think Transfer supports this yet), and do you have any patterns that allow you to generically describe value objects using metadata and to gen good admin interfaces, SQL code and the like?
Any thoughts appreciated!
With DB schemas, you often denormalize for performance. With CF, you have to do the same thing at the object model. And then we get these bizarre "patterns" like iterating business objects that are 100% band-aid for a fundamental flaw in the language/runtime.
To me, the benefits of an CF-based ORM solution are nullified by the complexity, the extra hackery you have to add to get sufficient performance for production apps, and how limiting they are. Transfer now has TSQL (a la HQL), which was one of my major gripes for a long time. I haven't played with it to see what I can do, but It's so much easier to just accept the fact that CF isn't the right tool for the job.
To get back to the point, value objects are must-have concept for a full-on ORM tool, but for CF tooling they're far less relevant because of platform limitations.
It's recognition of concepts like entities vs. value objects and the idea of a component object that make Hibernate really click with me. It encourages you at every turn to think in terms of objects, and these distinctions within the ORM's mappings are reflective of the consequences of OOD instead of a reflection of the consequences of relational storage, keeping the abstraction moving in the correct direction.