Regarding "How can we test applications?" in S2 doc online

[Skip Hollowell <sk...@skipdaddy.com>]

"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

Testing and jUnit test cases look like they may take as long as the dev 
itself, but it's gotta be done.


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

Re: Regarding "How can we test applications?" in S2 doc online

[Laurie Harper <la...@holoweb.net>]

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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Regarding "How can we test applications?" in S2 doc online

[Dave Newton <ne...@yahoo.com>]

--- Skip Hollowell <sk...@skipdaddy.com> wrote:
> My question lies in how do you scale this for 10
> actions?  20?  50?

Typically (well... in my little world, anyway...) the
bulk of functionality is wrapped up in service objects
which are used all over the place, including
stand-alone apps etc.

> LoginAction extenbs LogonActionSupport
> LogonActionSupport extends ActionSupport (or do we
> skip this second layer, and have it extend 
> Preparable?) ActionSupport extends Preparable, etc

I'm not sure what you mean here. In general I have an
action per URL or group of URLs dealing with the same
thing. This action will use injected services and/or
DAOs depending on how things fit together the best.

> Testing and jUnit test cases look like they may take
> as long as the dev itself, but it's gotta be done.

Testing usually takes longer, in my experience.

d.



       
____________________________________________________________________________________You snooze, you lose. Get messages ASAP with AutoCheck
in the all-new Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_html.html

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