Some More Persistence Patterns
Serializable Value Objects
This takes the idea of value objects one step further, allowing you to serialize an entire value object into a single field, so you might have an Order.BillingAddress field into which you'd serialize the collection of properties of the BillingAddress in some kind of textual or binary format. This is interesting, but I'm having a hard time immediately coming up with use cases. Anyone came across a good use case for serialization of composed value objects within the db?
Calculated Properties
In this feature, Hibernate allows you to put some of the processing into the DB so instead of writing a custom getter in Java for OrderItem.getTotalPrice() = getUnitPrice() * getQuantity(), you can just state the TotalPrice property has a formula of UNIT_PRICE * QUANTITY. I considered this feature in the last version of my data mapper, but decided to consolidate my business logic in a programming language rather than in the db, but I can understand the use cases for this - especially as part of a general purpose framework.
Generated Properties
This was also something I build into the last version of my Data Mapper. The ability to have date/time stamps or (in my system) ID's auto generated (Hibernate treats the identity as something special - not just another property). In Hibernate you can set generated="always" or generated="insert". This is absolutely required for non-trivial systems in my experience.
Default Values
Implementing default values is one of those things that seems simple until you think through all of the possibilities. If an object has default values, should they be displayed in an add form? Sometimes, if a guest user doesn't have a FirstName yet, you might want to say "Hello Guest User" - displaying "Guest" as their "default" FirstName. Clearly when you have a Register form, you don't want to default FirstName to Guest. Equally, if FirstName is optional and non entered, you don't want to save "Guest" to the db. I'll work up another posting later today on default values, but let me just say that it's something that I had to think through quite carefully last time round to capture all the feasible levels of "default" for a given object property within an application.
So, what do you think of these capabilities? Anything you like/dislike? Anything else you think should be included within a persistence framework?
I think also, when it comes to default values, one has to decide whether they are the responsibility of the Model or of the View. Going back to your "Guest User" example, let's say we know that a user is not logged in because they have no ID (or that ID is zero). Do you think the concept of a "Guest" should be something that is modeled? Or do you think that it is merely something that should be displayed?
Meaning, do we have something model-based like:
Hello #SESSION.User.GetFullName()#
... or, do we have something view-based like:
<cfif SESSION.User.GetID()>
. . . . Hello #SESSION.User.GetFullName()#
<cfelse>
. . . . Hello Guest User
</cfif>
My gut feeling is that this is something that is View-specific and therefore, "Guest" is not a default value of the model.
FWIW, the way I access this stuff is my framework always loads a SiteUser into my event bucket (I call it PageRequest), so it's something like:
<cfset SiteUser = PageRequest.get("SiteUser")>
Hello #SiteUser.get("FullName")#<br />
That said, I'd agree this isn't the best example that relates to defaults and this is an arguable choice. A better example might be the difference between a default in a form and a default in the database, but let me work up that posting and we can discuss it there!
Say you have an existing schema that mapped well to your objects, except for field X that happens to be a list of values. You can use Hibernate to define list functions and use them in your HQL, rather than having to pull objects back up into Java and filter the collection there.
Definitely an edge-case tool, but it can be a handy one.