The original idea was that one Data Transfer Object could be used to represent many domain objects. Perhaps even *all* the domain objects. The view tier could then ferry back and forth this one object instead of having to deal with a plethora of finely grained objects. All the view layer sees is a coasely grained Data Transfer Object or two. (I tend to use two, one for select lists, and another for everything else.)
The pattern is most useful when the view and model layers are actual tiers: They live on separate machines and the object is being remoted between machines. Another case is when you are enforcing very strict separation between the view and model layers, and do not want the view layer to know your elegant, finely-grained model even exists. If neither of these cases is true, then there is little reason to use the pattern. Some people dislike the pattern because it is often misused. The underlying idea is to "normalize" the properties that view needs to use. If we skip normalization, and the DTOs end up mimicking the domain object graph, then the purpose of the pattern is not served, and the DTOs devolve into busy work. -- HTH, Ted. http://www.husted.com/poe/ On 10/17/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi, Gurus, > > Background: I just started a Struts project with Hibernate. I have chosen to > use the Data Access Object with (Abstract Factory) design pattern because my > client uses Oracle and I use Postgresql database. I am working with other > teams remotely and they decided to use DTO. > > Problem: A few months ago, I recall a message thread on this list with a > subject header of: 'DTOs are evil'. Since I am new to this, I am having > problems understanding why. I thought that DTO are for data storage and data > transfer between Business and Value Objects. > > Questions: I have the following questions: > > 1. Why I shouldn't choose it? > > 2. Should I be using the Apache Commons BeanUtils in my action? It has a > method like BeanUtils.copyProperties(...). > > 3. If not BeanUtils, then what do you recommend? > > > Thanks, > > Bob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
