You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Mark Ayad <ma...@javamark.com> on 2002/11/12 00:11:48 UTC

Re: [SIDEBAR] Form population (Was RE: request.setAttribute() formconfusion)

Like Eddie Says use DAO pattern it makes life much easier, and gives you a
very valuable abstraction layer.

Mark

----- Original Message -----
From: "Eddie Bush" <ek...@swbell.net>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Tuesday, November 12, 2002 1:00 AM
Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute()
formconfusion)


> edgar wrote:
>
> >OK Eddie, what do you use to model the business logic?
> >
> Classes which aren't dependant on Struts ;-)
>
> Seriously.  Most everyone is going to tell you to build things in layers
> - aiming for low cohesion between them.  Data goes "up" (through he
> layers) and dependencies go down (through the layers).  So it would be
> acceptable to have a business-domain layer built on top of your
> persistence layer - but not versa-vice (er vice-versa too).  Encapsulate
> everything you can using good OO methodologies and make it all as stupid
> as you can.
>
> So you have ... something like ...
>
> ActionClasses make calls to
>     Business logic beans (delegates, if you like to call them that)
> which make calls to
>         DAOs (or other persistence mechanism)
>
> The action probably instantiates a VO/DTO and does a copy and passes
> things to the BLBs.  That's how I tend to go about it.  So you're just
> mapping from the view to your model in the action (or model to view if
> your outputting).
>
> Build the system to be UI-agnostic.  Then, use the actions as an
> opportunity to retrofit for Struts being the view.  Translate the HTTP
> request into whatever inputs your BLBs take (probably VOs or DTOs
> depending on the name you like to use) using BeanUtils or something else
> to do a copy and then shoot things off to your BLBs.  Then, take the
> outputs and ... well everything in the action-class is UI-centric but
> you can probably acheive a better (more usable - easier-managed) design
> by taking advantage of encapsulating things and then just building on
> top of that - "on the shoulders of giants" as the phrase goes.  That
> speaks volumes about OO IMHO.
>
> If your DAOs know how to do your data-access - and they work solid - you
> needn't bother reproducing that effort anywhere else.
> If your BLBs know how to run your business, provided your DAOs - and
> they work solid - you needn't bother reproducing that effort anywhere
else.
> You may even choose to throw a layer on top of the BLBs - an API
> (facade, if you like) or ... well, there's a myriad of ways ...
>
> If you have your logic inside of form beans then you can't use that
> logic without importing org.apache.struts.* stuff - and your business
> logic should have zero dependencies on Struts.  What's going to happen
> when you change and go to another framework (ok that's probably not
> going to happen, but ...) - or you build a SWING GUI to run the show for
> your tech support guys?  If you have your logic encapsulated in
> UI-agnostic things (the BLBs) then it really doesn't matter - just write
> wrappers around your BLBs that adapt them to the SWING GUI.
>
> Clear as mud?  Someone help me here - I suck at explaining the why and
> wherefore ...
>
> >-----Original Message-----
> >From: Eddie Bush [mailto:ekbush@swbell.net]
> >Sent: Monday, November 11, 2002 6:16 PM
> >To: 'Struts Users Mailing List'
> >Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute()
> >form confusion)
> >
> >
> >My apologies - you were going after edgar - and rightfully so :-)
> >
> >edgar:  Listen to Sri the wise ;-)
> >
> --
> Eddie Bush
>
>
>
>
> --
> 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>