I am using struts -> Java Object (business Tier, e.g. Spring) -> Hibernate.
General practice for sendnig data to DAO is through DTO/VO for coarse grain data transfer. With hibernate we have POJO which is same as DTO. Is it good practice to use POJO for data transfer from presentation tier to Hibernate DAO, that means web tier will instantiate the POJO class, populate the POJO object and send it to DAO for persistence. Or, shall we create separate DTO and separate POJO class ???
Basically, the DTO pattern arised because we couldn't serialize Entity Beans, but with Hibernate and Detached objects, you no longer really need DTOs, you can transfer the persistent objects, you can create new instances (transient instances) on the client, attach it to a Hibernate Session and then save it to the database, Hibernate will see it is transient and correctly insert it into the database.
If you had persistent POJOs and seperate DTOs, well now you would have to write extra code to take the values from the DTO and put them into a POJO, kind of extra work for nothing in my mind.
Depends on the nature of your useage. If your POJOs contain only getters and setters then by all means bring them directly out of your store, but sometimes POJOs have real work to do and in this case it can be difficult to bring directly from the store. Sometimes POJOs dont expose their internal data through getters and setters and in this case how do you store them without adding new methods just for storage?
Besides, if all it has is getters/setters it IS a DTO.
Originally posted by manuel aldana: but beware of code duplication. for maintenance it could be quite messy if you have to keep your model-design up to date in two implemented data-models (hibernate pojos + dto).
How would that scenario come about?
Get me the mayor's office! I need to tell her about this tiny ad:
SKIP - a book about connecting industrious people with elderly land owners