• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • paul wheaton
  • Ron McLeod
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:

Design issue (POJO and DTO/VO)

 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ???
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Mark
 
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Manju Singh
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your reply.

Atleast, I got the clear picture of this. And, decided to go ahead with the mixture of POJO and VO depending on the reqmt.
 
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic