Am I right when I have:

One business logic class, say PersonDO, which have a PersonDAO - the HQL and session.save() and session.update() stuff, and a PersonVO - the value object, which is the actual Hibernate mapped object. Like this:

class PersonDO {

PersonDAO personDAO;
PersonVO personVO;

public PersonDO() {
this.personDAO = new PersonDAO();
}

public PersonDO(PersonVO personVO) {
this();
this.personVO = personVO;
}

public findByPk(long id) {
return personDAO.find(id);
}

public void complicatedBusinessMethod() {
// this method is complicated but only operates on the
// attributes and relations of the PersonVO object.
// it also does some DAO-calls
}

// and only the getters and setters from the VO-class we want to expose to the business
// service and business workflow tiers, not the whole shebang of Hibernate
// mappings.

}

class PersonDAO {

HibernateSession session;

// session.save() and session.findBySomeAttribute() and so on....

}

class PersonVO {

protected String someAttributeFromDB;
protected String someOtherAttributeFromDB;

// and the getters and setters

}

By having this separation, it's easy to have a base value object from the Hibernate mappings, one business object that operates on this hidden inner value object, and the DAO and VO objects hidden from all other tiers than the business logic tier.
However, it's also difficult because since you want to have the VO object hidden from all others, all VO object references must be translated to a corresponding DO object before we can communicate it with other tiers och business objects.

Can anyone see a better approach using interfaces or proxies to some extent? I can sort of feel like there is a better solution, but it doesn't pop up to me.

I don't want to use the VO object as a data transfer object since we already have a tier with DTO's in our architecture. These DTO's are XMLbeans enabled objects and created from the DO objects. Thus, the architecture use xml as the DTO mechanism and this isn't very suiting for the Hibernate VO objects.

Best Regards,

Niklas Gunnarsson
Sweden

you don't need "value object", hibernate is meant to persist BusinessObjects (domain model).

By having an interface for the business object, the "DO", we can hide the unwanted getters/setters and attributes in the VO.
Then, in the mapping file, we tell the class to have the DO as the proxy.

Niklas

Now your domain object is no longer technically neutral, i.e. it depends on hibernate (indirectly through the DAO). I thought that is contradictory to hibernates philosophy.

You can already hide unwanted getters/setters by having private fields without getters/setters. Hibernate can map directly to/from (private) fields.