stateful vs. stateless Actions / Struts design question

["Heydtmann, Dirk" <dh...@sprintspectrum.com>]

Hi,

In our company we are thinking of extending the RequestProcessor and
overriding processActionCreate(), in order to optionally (based on a custom
ActionMapping property) store Actions on the session rather than sharing
Action instances across sessions. This is to minimize impact to our existing
applications, as we are replacing our legacy MVC framework with Struts.

I suppose that the Struts design reason for keeping Actions stateless was
that (a) this is more lightweight and (b) state is normally tracked in the
ActionForm beans. Is this correct? (Unfortunately, our legacy apps do not
use form beans yet). Any thoughts, comments?

Thanks

Dirk Heydtmann




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

Re: stateful vs. stateless Actions / Struts design question

["Craig R. McClanahan" <cr...@apache.org>]

On Fri, 30 Aug 2002, Heydtmann, Dirk wrote:

> Date: Fri, 30 Aug 2002 12:48:55 -0500
> From: "Heydtmann, Dirk" <dh...@sprintspectrum.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: struts-user@jakarta.apache.org
> Subject: stateful vs. stateless Actions / Struts design question
>
> Hi,
>
> In our company we are thinking of extending the RequestProcessor and
> overriding processActionCreate(), in order to optionally (based on a custom
> ActionMapping property) store Actions on the session rather than sharing
> Action instances across sessions. This is to minimize impact to our existing
> applications, as we are replacing our legacy MVC framework with Struts.
>

I guess this would also let you use instance variables in the Action
classes (although you still need to be mindful that multiple simultaneous
requests per session are still possible).

> I suppose that the Struts design reason for keeping Actions stateless was
> that (a) this is more lightweight and (b) state is normally tracked in the
> ActionForm beans. Is this correct? (Unfortunately, our legacy apps do not
> use form beans yet). Any thoughts, comments?
>

Those are two good reasons.  A more important one has to do with the
architectural role for Actions -- they should be seen primarily as
adapters between the web tier APIs (request, session, and so on) and your
business tier objects.  An Action is, unavoidably, tied to servlet APIs.
Business logic objects should not be -- you want to be able to reuse them
in non-web-tier environments as well.

The canonical application design, then, is to create a stateful session
EJB (or equivalent sort of JavaBean if you're not using EJBs) that
contains the actual business logic methods.  The API for these beans
should *not* include any web tier imports (i.e. don't import any class
that starts "javax.servlet") -- that would compromise reusability.

If you use this approach, an Action should basically just implement the
Adapter pattern [GoF], translating things like request parameters and
cookies (and form beans -- you don't want your business logic importing
Struts classes either) into the types of value objects or other data that
your business logic classes require.  Actions that do this kind of thing
don't need to maintain any state, so there is no reason to spend the
overhead of having more than one instance of them hanging around.


> Thanks
>
> Dirk Heydtmann
>

Craig


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