edgar wrote:
Classes which aren't dependant on Struts ;-)OK Eddie, what do you use to model the business logic?
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: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
