• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

where to create DTOs

 
pranith rao
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
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac 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
Sheriff
Posts: 17278
6
IntelliJ IDE Mac 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
 
Stan James
(instanceof Sidekick)
Ranch Hand
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
Sheriff
Posts: 17278
6
IntelliJ IDE Mac 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
 
Michael Duffy
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)
Ranch Hand
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
 
Michael D. Brown
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic