• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Junilu Lacar
  • Martin Vashko
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Scott Selikoff
  • salvin francis
  • Piet Souris

where to create DTOs

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I am working on a project and folllowing the below pattern

view(struts) ------>controller -----------> bussiness delegate -----------------> service locator + DAO (Data Access Object) ---------------------> Hibernate entity

the view uses DTO (Data Transfer Object) to display. Where do I create the DTO? Do I have to use transfer object assembler? If I have to use transfer object assembler is there any tool to create it (for eclipse) and where do I access the transfer object assembler? Please advice

Thanks,

Pranith
 
ranger
Posts: 17344
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Hibernate entity



Usually your DTOs are also the Hibernate "entities" The are JavaBeans that are Plain Old Java Onjects, then you have those objects mapped through Hibernate to your database tables. So you can use the one object for both things.

Mark
 
pranith rao
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Mark Spritzler:


Usually your DTOs are also the Hibernate "entities" The are JavaBeans that are Plain Old Java Onjects, then you have those objects mapped through Hibernate to your database tables. So you can use the one object for both things.

Mark



Thanks. But wont it create a problem if we access a lazy collection in an object (collection which hasnt been fetched)

Pranith
 
Mark Spritzler
ranger
Posts: 17344
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, that would cause aproblem, so it you want to send the entire heirarchy, you would have to fetch all the data that you want to pass back to the client.

Mark
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does that ever give you the feeling you have exposed your data model to the view? We use a vendor framework that does just this ... builds POJO beans at the data accessor and passes them through business services right out to clients like the UI. I sometimes wonder if the business service shouldn't transform them into more stable and generic objects. The only place we actually do this is transforming product information from many sources - MQ series, web services, etc - into a common structure.
 
Mark Spritzler
ranger
Posts: 17344
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well our objects are simple, and represents the Object Model we want to deal with on both server and client side. The Data Object doesn't have anything that the client isn't using, whether we place the data in just the Data Object, or then into a DTO, they would look identical anyway.

Mark
 
Ranch Hand
Posts: 163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Personally, I'm not that worried about exposing objects to the view. If people aren't putting business logic in JSPs, and they're using JSTL to avoid scriptlet code, they won't be calling methods in view that go beyond accessing data.

I think DTOs are an anti-pattern that arose from entity bean behavior. If you use Spring and POJOs it's not a problem.
 
pranith rao
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Thanks for your replies. One of my friend suggested to keep the hibernate session open in the view so that lazy fetching does not effect. What do u think?

Pranith
 
Michael Duffy
Ranch Hand
Posts: 163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Or you can close the session, put the objects into the detached state, and let the view use them that way.

%
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I think DTOs are an anti-pattern that arose from entity bean behavior. If you use Spring and POJOs it's not a problem.



I often call them a necessary evil in some architectures. There are often boundaries that meaningful objects do not pass over and DTOs are one way to get data across. Stateless web architectures look an awful lot like pseudo-conversational mainframe CICS apps I made in the prior millenium, and the new "continuation based" frameworks try to emulate true conversational. There is not much new under the sun
 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Michael Duffy:

I think DTOs are an anti-pattern that arose from entity bean behavior. If you use Spring and POJOs it's not a problem.



Wow...so you're saying that Martin Fowler doesn't know what he's talking about, because DTO is a pattern within his book.

Sometimes, it might make more sense to define objects that are separate from your domain model (essentially what Hibernate beans are) for passing around data. Maybe your domain model contains business logic that you want to keep in the back. Maybe you want to provide one function call (on a Facade for example) that returns everything a particular view needs. Maybe you don't want to keep your hibernate session open for the entire request because it makes your view/controller cognizant of the implementation of your model. For whatever reason you might have, sometimes it makes more sense to create separate DTOs from the Domain Model.

To answer the original poster's question, your DAO should be responsible for creating your DTOs. That way it can open the Hibernate session, pull the appropriate objects, make the copies to the DTO and close the session when done.

Just my 2 cents...

Michael
 
When I was younger I felt like a man trapped inside a woman’s body. Then I was born. My twin is a tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!