In a truly multi-layered architecture with a real thick client, not some web-based client in a servlet container in the same JVM, we tend to use assemblers that build data transfer objects out of our rich domain layer that we send over the wire to our clients. (Can anyone say buzzword bingo? Sorry 'bout that)

Question:

I'm interested to know whether in addition to the above if anyone is also creating a layer, possibly within their DAO layer, of Hibernate Entity objects? They would then transform the Entity objects into the corresponding domain object.

Recently we've leaned towards creating this layer, but have currently postponed it as a refactoring debt for our project.

Some of our experiences that are pushing us in this direction are:

Domain designers are split on usage of public accessors in domain objects (that's another can of worms though)

API dependency in other layers. For example, Hibernate's sneaky replacement of collections makes our assemblers, which are in a separate jar, have a dependency coupling to Hibernate.

Introduction of non-domain-domain objects. For example, entities that require composite ids require composite key entities. The consensus is that although this is rather necessary for our Hibernate DAO implementation this pollutes our domain layer. An argument her might be the adoption of surrogate keys (yet another can...).

Any comments are welcome. Please don't make me look too foolish :).

Regards,
Roll

I'd appreciate any comments from the community and would happy to elaborate if req'd.

Regards,
Roll

Hibernate is for persisting your domain objects.

I can't imagine a case where you would want another persistent "entity layer" that is not your domain layer itself.

As for DTOs, we have written our own XML-RPC wrapper that allows us to send arbitrary beans using XML-RPC. This wrapper converts collections to be generic Java collections, avoiding the "need Hibernate on the client" problem. We don't fret about exposing all public methods to the client.

If we DID fret about exposing all public methods to the client, we might want a DTO layer, but it has so far been a losing proposition to put in the heavy work of making a general DTO layer.

Cheers!
Rob