Most of the examples and documentation for Hibernate reflects the primary usage of Hibernate: web applications. We have another goal - to create a Swing (or SWT) application which uses Hibernate as an abstraction/persistence layer between the GUI and the database. We need this to run client/server.

We are very familiar with Apple's Webobjects/EOF which allows you to fairly neatly separate the business logic by running the EO classes at the server side and keeping only GUI code in the Swing client. Can we use this approach with Hibernate? Basically, I'd like the Swing client to share enterprise objects (or whatever the equivalent is called in Hibernate) with the server machine, but for the majority of Hibernate code to run on the server. That Hibernate code then interacts with the database over JDBC on the same machine.

I know I probably haven't used the right Hibernate terminology, however I think this approach is sometimes described as 3 tier.

Am I on the right track with this?

Does anyone have examples of type of implementation or can point to any commercial applications which have been written in this way?

We would love to leverage our Java experience into being able to create client/server database centric applications in this way, but I'd like to know that I am on the right track.

Thanks in advance...
Ari Maniatis

I've not used it (having only ever done webapps with Hibernate), but I think what you need is the detached object support? Try a forum search for the word detached for some more info.

I'm currently working on a project where we have rich Swing clients as well as web-based thin clients, and a middle-tier that has a concrete Hibernate DAO implementation.

Our web based clients take full advantage of our domain model, or enterprise objects as you mentioned. However, for our thicker clients we've chosen to use the DTO and Assembler distribution patterns because of performance issues with far reaching end users and where injecting our huge graph of domain objects isn't performant (these reasons are of course debatable...).

If you and your team agree to injecting the domain objects directly into your clients, then as stolley has already suggested you will definitley need to use detached object support. Note you'll have to couple your client to Hibernate as you will discover by researching on detached objects and domain objects in your view, however, this too is debatable as to whether it is a good or bad practice...

I think it ends up depending on what you're doing. For the last couple of apps that I've done, I've used custom dto patterns for all of our client apps. However, our products have a system management utility which essentially does CRUD operations on entities. The custom dtos kept ending up looking exactly like our domain objects. The stress in trying to share code and behavior between client applications was becoming a pain.

At any rate, for me passing domain dtos to this particular client isn't more data or trouble than the custom ones. When a particular use case requires a vastly different view of the data, I certainly intend to create custom objects for it, and I'll assemble them elegantly. For my other applications, custom dtos make a lot of sense. I'm just not buying into an entire layer of indirection that I'll mostly not use. (See Refactoring: Speculative Generality, Shotgun Surgery for more detailed reasons)

Phill