I am using Hibernate (could be any other O/R tool) to provide data
persistence for a web application. The Hibernate 'domain' classes are
hand-coded to include XDoclet tags for O/R mapping. I have a small number of 'first level' objects (where indepedant PK lookups would be used) and a larger number of second-level objects where access is always via a first-level object.

However, I would like to generate ValueObjects (or DTOs - Data Transfer Objects) from the Hibernate-XDoclet classes without having to turn the Hibernate classes into EJB's - an apparant limitation of the current XDoclet <value-object> sub-task. Can this be done? Does anyone have sample code?

I would like to ensure that the application can be scaled between multiple servers. It would appear that I need to generate SLSB and/or EJBs to do this from the Hibernate first-level classes, and it is these generated classes which would use the original Hibernate-XDoclet classes for bean-managed persistence. I cannot find an XDoclet mechanism to generate the Beans's - all the XDoclet tasks I can find seem to be based on manually creating the EJB first. These EJB's would expose various methods to allow access to the rich data structure implemented by the DAO mechanism. Can this be done? Does anyone have sample code?

Would it be better to convert each Hibernate DAO into BOTH an EJB and a
Hibernate-managed class? This approach seems complicated due to unkown impact of using Hibernate specific collections and that second-level objects should not be exposed as EJB's and all access controlled by the first-level object.

The implementation would then continue to use the Struts XDoclet tags etc to generate more of the web tier from the DAO Hibernate classes.

I am relatively new to XDoclet, and not experienced in creating tasks and
using xdt (though have used Velocity, so the concepts are familiar).

Can anyone make some suggestions?

Thanks,

Peter Millington

Why do you need value objects?

Value object were introduced by xdoclet ( first there were data objects ) because remote performance of ejb is really poor,
and EJB ( at least entity ) is really sucky architecture.

With hibernate you do not need value objects - your persistent classes are value objects.

I would recommend:
- POJOs persisted by hibernate
- DAO layer which encapsulates business logic
( can be turned into session bean if you like )

- you can place struts form tags on the very same sources
( though I would recommend to evaluate webwork instead.
Is much better in use, but poor documented )

Why value objects ? ...

Value objects would not contain all fields/properties from the database, such as 'last-modified', child collections, calculated values etc.

Note that "value object" is often a synonym for "DTO", but "value object" can also mean other things. If you mean "value object" in the same sense as "DTO", then you might want to check out this topic about DTOs in the misc forum.

http://forum.hibernate.org/viewtopic.php?t=925966