You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by bj...@yahoo.com on 2005/10/17 16:26:08 UTC

What's wrong with DTOs?

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

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: What's wrong with DTOs?

Posted by Borislav Sabev <b....@eventsoft.de>.
bjester_2004@yahoo.com wrote:

Hi Bob, I'll try to give my 1 cent to the topic and also to answer you 
more concrete because I believe you want some concrete answers, not 
theoretical conversations.

>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.
>
>  
>
Why do you mention DTO and DAO here together? I think that they are 
known solutions for very different problems ... (at least my opinion is 
that DTO doesn't have anything to do with DAO)
Btw, Hibernate abstracts already your access to the database (i.e. 
doesn't matter if it's Oracle or Postgres unless you use some special 
features from these RDBMS). Just change the driver settings in the 
hibernate.cfg.xml and it will work transparently with chosen RDBMS.

>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?  
>  
>
You will use them even if you don't want - ActionForms are DTOs. They 
just save you the work to translate the request parameters in more 
convenient form. You can consider also HttpServletRequest as DTO. 
ActionForms also have some validation functionality, but I almost never 
use it (except for the most simple cases).

>2. Should I be using the Apache Commons BeanUtils in my action?  It has a method like BeanUtils.copyProperties(...).
>  
>
Personally, I use BeanUtils all the time, because it saves me a lot of 
writing. If your forms change very often i.e. you add/change/delete 
fields to/from them, then I recommend you mapped forms - a form with a 
map and all BO properties are copied from BO to this form map and vice 
versa. The difference is also how do you use the map in jsp tags - 
instead of writing something like this <html:text property="city"/> you 
have to write it <html:text property="mapvalues(city)"/>
When I use mapped forms I can change very fast the whole content of a 
form because the changes are only in 2 places (where they should be) - 
in the BO and in the jsp. If you use "normal" ActionForms any change 
will force you to touch other 2 files: the struts-config.xml and derived 
ActionForm class.

>3. If not BeanUtils, then what do you recommend?
>
>
>Thanks,
>
>Bob
>
>  
>
The best way is just to try 2-3 different approaches and see what are 
the advantages and disadvantages of every one. Then you can decide how 
and when you can use them all or only one.
Or say it in other way - first find and define unambiguously what are 
you problems and then search the appropriate solution.

Regards
Borislav

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: What's wrong with DTOs?

Posted by Aldo Vadillo Batista <al...@gmail.com>.
I think DTOs is the best solution.
However, is tedious to copy properties. Yes, I know that you can use
BeanUtils but sometimes you need a DTO that is a combinations of two model
objects and you have to use getters and setters.

 2005/10/17, Vic Cekvenich <ne...@roomity.com>:
>
> I don't think anything wrong w/ DTO.
>
> You have your DAO, your model... in my case I use collections as DTO,
> but beanutils is fine.
>
> .V
>
> bjester_2004@yahoo.com 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
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
>
>
> --
> thx,
> .V
>
> Your Roomity Broadband Community <http://roomity.com/demo.jsp>
>
> cell: 917 825 3035 in DFW
> email: netsql at roomity.com <http://roomity.com>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

Re: What's wrong with DTOs?

Posted by Vic Cekvenich <ne...@roomity.com>.
I don't think anything wrong w/ DTO.

You have your DAO, your model... in my case I use collections as DTO, 
but beanutils is fine.

.V

bjester_2004@yahoo.com 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
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 


-- 
thx,
.V

Your Roomity Broadband Community <http://roomity.com/demo.jsp>

cell: 917 825 3035 in DFW
email: netsql at roomity.com


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: What's wrong with DTOs?

Posted by Ted Husted <te...@gmail.com>.
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, bjester_2004@yahoo.com <bj...@yahoo.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org