To DTO or not to DTO ?

It seems like everytime on a project the question is asked again, why are we doing this? Why are we creating all these objects that just copy the attributes from Entity EJB's or Hibernate POJO's to a bean that is then sent to the presentation layer and visa versa. And then there are cries that DTO's are evil and I ask the question all over again. So does the team.

Conclusions:
A DTO provides a way of guaranteeing the scope of what you will send and what you will return between the presentation and business layers. For some domain models this is important for others not at all.

When you can use the business objects directly:

• The business object in question is at the end of the line. In other words there are no many-to-one relationships or dependancies tied to it. I get the object and I don't have to wonder if I have to get the collections attached to them and the collections attached to them, etc.

• The business object is just a bean. There are little or no process methods that you don't want to expose to other layers. For example what if there are business methods on the object like reset(), deleteAllStuff(), showBlingBling()
• Other cases?
  

Otherwise it's DTO city. Why? Even with lazy loading you still might not want to expose all of a graph of objects to another layer. And then what happens when you want to save or update? What do you persist? The whole graph? only certain parts? How to do define a boundary of the transaction? Well, DTO's or hierarchies of DTO's are a way of limiting the scope of the transaction at hand.

I'm going to check into the "Open Session in View" pattern and playing with Spring's OpenSessionInViewFilter and Interceptor.