Skip Hollowell wrote:
"First, push as much business and data access logic as possible out of
the Action class and into a POJO facade that the Action can call. In
this way, you can test all that outside of the Action."
My question lies in how do you scale this for 10 actions? 20? 50? Do
you have 1 facade for all actions (ActionSupport.java) or do you break
it down more granular (LogonActionSupport, LookupActionSupport, etc)?
If so, do you recommend then that I keep 1 main support class that each
of these secondary support classes extends?
LoginAction extenbs LogonActionSupport
LogonActionSupport extends ActionSupport (or do we skip this second
layer, and have it extend Preparable?)
ActionSupport extends Preparable, etc
Err, no, the idea is for the POJO facade classes to form a completely
decoupled service layer -- i.e. they should know nothing about Struts,
HTTP, etc. The service layer provides a platform-agnostic API for
invoking business functionality, which your actions (or anything else)
can then call.
Your actions don't inherit from the facade classes; they may inherit
from Struts' ActionSupport class, but they just call the service layer
classes directly as needed.
How you organize your service layer depends on your application. For a
simple app, a single POJO could provide the complete facade and all
actions would call that one POJO. For a more complex app, you would
probably break the service layer into multiple classes to keep things
sane, but there's no requirement that there be any direct mapping
between actions and service facades; in fact that's exactly the kind of
coupling you want to avoid.
Testing and jUnit test cases look like they may take as long as the dev
itself, but it's gotta be done.
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
