Stupid email filters [WAS: DAO -> DTO business object to view beans]

[Andrew Hill <an...@gridnode.com>]

Ok whats wrong with this thread?
Seems it offended someones highly touchy content filter.
duh! <tries-to-clap-but-the-hands-miss/>

<stupid/>
Trend SMEX Content Filter has detected sensitive content.

Place = Struts Users Mailing List; ; ; Struts Users Mailing List
Sender = Andrew Hill
Subject = RE: DAO -> DTO business object to view beans
Delivery Time = August 20, 2002 (Tuesday) 11:48:58
Policy = Blocking07292002
Action on this mail = Quarantine message

Warning message from administrator:
Content filter has detected a sensitive e-mail.
</stupid>




-----Original Message-----
From: Andrew Hill [mailto:andrew.david.hill@gridnode.com]
Sent: Tuesday, August 20, 2002 23:56
To: Struts Users Mailing List
Subject: RE: DAO -> DTO business object to view beans


Have to agree.
My ActionForms started out looking very like the objects I use to access the
data from the j2ee side, but the speed at which they diverged over just a
few iterations was quite surprising....

-----Original Message-----
From: James Higginbotham [mailto:jhigginbotham@betweenmarkets.com]
Sent: Tuesday, August 20, 2002 23:11
To: Struts Users Mailing List
Subject: RE: DAO -> DTO business object to view beans


In my past experience, projects tend to start out with the DTOs matching
the BOs 1-to-1 but as a project grows and matures, UI changes will
require a DTO to change in such a way that they don't match the BOs
anymore. So, do the right thing and have both BO and DTO, even if they
are matching. This will give you the buffer zone you need to be able to
change one or the other. If you want to automate the transformation, I
think there is a transformation library in the Struts resources page
(somewhere) that is supposed to help in this mapping. Worst case, take a
look at the apache commons bean utils that Struts uses to help automate
the transformations.

James

> -----Original Message-----
> From: Alex Birch [mailto:alex_d_birch@yahoo.co.uk]
> Sent: Tuesday, August 20, 2002 9:18 AM
> To: struts-user@jakarta.apache.org
> Subject: DAO -> DTO business object to view beans
>
>
> Hi,
>
> I am building a medium size struts application (40-60 jsp
> pages) in a team.
>
> my question is to do with mapping business objects to view beans...
>
> By view beans I mean DTO (data transfer objects mentioned by
> Chuck Caveness in chapter 7 his upcoming O'Reilly struts book)
>
> If my understanding is correct, to maintain the abstraction
> between the presentation layer and the business layer,
> business objects should be mapped to DTOs. DTOs are stateless
> and represent a partial view of your model to be represented
> on a single JSP page.
>
> We have adopted this policy quite literally and have designed
> our DTOs totally separate from the BO's (with re-use where possible).
>
> There are many instances however where our BOs are simply DAO
> (data access objects) which do not differ at all from the view beans.
>
> We as a team are arguing whether it is better to break the
> abstraction and use some of our BO's straight for display in
> the view (the BO's aren't persistant so there's no worry
> about accidental state manipulation). You can imagine with 40
> or so JSPs how many view beans there are - and a lot of them
> will be straight theDTO.setProperty(theBO.getProperty())
> which is also inefficient.
>
> Has anyone encountered the same superfluous nature in this
> scenario? The DTO's/viewBeans are not coupled to the
> presentation layer in any way seeing as they're just snapshot
> java beans with no specific struts implementation.
>
> Is there a big no-no that I haven't seen which means I
> shouldn't use the BOs for the view?
>
> thanks for your time in advance
>
> Alex
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts http://uk.my.yahoo.com
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>

--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>