Hi Folks…

I’ve been looking for some steer on implementing Hibernate in a structured / layered application.

The basic axiom being adhered to is the standard approach of having each layer dependent on the one below. We’ve the standard web/business/data layers making up our ‘stack’. As we’re not interested in a distributed architecture right now we’re not concerned with inter-VM communication. This will not be discounted for the future, so we’re trying to employ certain best practice so as not to cause problems further on.

Looking over the hibernate forum and other web references it seems very confused as to what the best strategy to employ in terms of what is passed from business to web and vice-a-versa. The page http://www.hibernate.org/124.html starts the debate but delivers very little in terms of guidance. I’d be delighted if this thread could manifest into something of use to myself plus others in terms of making such decisions.

I’m generally opposed to passing domain objects up to the presentation code, in our case ‘struts actions’. Doing so could lead to presentation code updating those objects directly (surely a mistake). As such, the purest approach I would take is to use immutable DTO(s) (data transfer objects) to relay this data to the presentation layer. Such objects would be orientated to the requirements of the display, the mapping to which would be performed by classes within the business layer. I’d argue this is valid because at this layer these presentation objects remain presentation / web layer agnostics. That, of course, is one on the motivators to having the layers in the first place. Updates would be presented to the business layer through the service façade to an interface specific on the operation I’m performing.

One problem I perceive here with Hibernate is because reattachment requires the original hydrated business object. I guess in a distributed solution this would lead us to use a ‘state-full session bean’ in order to hold onto the appropriate domain objects prior to update. Does this make sense?

In reality, because of our single VM we’ve chosen to wrapper the domain objects in ‘read-only’ (RO) adapters. These in effect wrapper the domain object exposing only the getters. They’ve proved beneficial in other respects, for example manifesting sets into arrays for type safety.

One potential problem we’ve come across with this technique is with how much of the domain model we draw out to the presentation layer. By returning a single major domain object wrapper the presentation layer code can in turn navigate the entire object graph. The service layer then becomes a little thin, a single getDomainObject(long id) method !!! This appears in certain respects to be pulling too much of the business layer into the presentation – web layer. Am I alone in this impression?

We’ve tried to tamper the creep of domain model into the web layer by having a notion of ‘high level’ domain object where associations to these have been replaced with a getter to the id/key. A further service call is needed to return that association as a wrapped domain object (RO).

One other area of confusion is the choice between fine & course grain business objects. Our use of fine grain objects has led us to skew their design toward UI requirements. I’m questioning the wisdom of such an approach, but beyond being uncomfortable I’m not sure how to articulate this (got a bad smell, but can't describe it!!!)

I hope this is good basis for a discussion, and I'm genuinely interested in anybody’s view (apologies for the length of this item).

Steven Crowe.

In my previous post about "open session in view" (that wasn't clear! ;) ), i wanted also to ask about that.
Expecially with this "pattern" you tend to have only a getDomainObject(id) in the business layer, and then attraverse the object grapth starting from this reference in the view.
Maybe it would be better to prepare the view with more source code, and then to do only very simple operation in the view.
I think that if we don't use the "open session in view" maybe we have more a bent for preparing the view in the controller.

Absolutely, how else should it work? You either keep the persistence context until the view is rendered or you prepare the data that is required to render the view before sending it to the view.

BTW, most of our ideas about these kinds of questions are answered in Hibernate in Action.