Joe, you could move your business logic to a service layer which
also leverages the Command pattern. You could have a base command
which did something similar as Craig has outlined.
public abstract class BaseCommand {
public void execute() throws Exception {
try {
// set up transaction
doExecute();
} catch (Exception e) {
// abort transaction
} finally {
// clean up transaction
}
}
// implement actual work here.
public abstract void doExecute() throws Exception;
}
then....
public class MyCommand extends BaseCommand {
public void doExecute() throws exception {
// put business logic here
}
}
in your action's execute method (be it DispatchAction, MappingDispatchAction, etc...)
public ActionForward execute(...) throws Exception {
ActionForward forward = // get appropriate forward
Command command = // get the appropriate command and initialize it
command.execute();
return forward;
}
You might also check out the Spring framework. It allows you to declaratively demarcate
transaction boundries (similar to EJB).
robert
> -----Original Message-----
> From: Joe Hertz [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 09, 2004 4:11 AM
> To: 'Struts Users Mailing List'
> Subject: RE: I suspect this is a bad idea...so what's a better one?
>
>
> Craig,
>
> Thanks for the idea.
>
> Only problem I see with this that I usually make my "real" actions some
> flavor of a DispatchAction, usually a MappingDispatchAction.
>
> So to keep that type of functionality, it appears that I'd have to
> replicate a lot of the Struts dispatch/reflection logic inside of my
> abstract Action subclass. Calling super.execute() gets me that, but that
> is precisely what this concept seems to try to avoid. :-/
>
>
>
> > -----Original Message-----
>
> :snip:
>
> > A useful design pattern for something like this is to create
> > a common subclass for your actions that does the
> > setup/teardown work in the
> > execute() method, and then delegates to the action-specific
> > work in some other method. For your scenario, it might look
> > like this:
> >
> > public abstract class BaseAction extends Action {
> >
> > public ActionForward execute(...) throws Exception {
> > Persistence persistence =
> > ActionHelper.getPersistenceObject(request);
> > try {
> > ActionForward forward = delegate(mapping,
> > form, request, response, persistence);
> > } finally {
> > persistence.release)(;
> > }
> > }
> >
> > protected abstract ActionForward
> > delegate(ActionMapping mapping, ActionForm form,
> > HttpServletRequest request, HttpServletResponse
> > response, Persistence persistence)
> > throws Exception;
> >
> > }
> >
> > Then, your real business logic is implemented in a delegate()
> > method that is passed in for you, and you never have to
> > remember to allocate and release the persistence object.
> >
> > public class RealAction extends BaseAction {
> >
> > protected ActionForward delegate(...) {
> > ... use the persistence object as needed ...
> > }
> >
> > }
> >
> > This is pretty close to what you've got now ... the key
> > difference is that it uses a local variable instead of an
> > instance variable to avoid sharing problems. Also, because
> > of the finally clause, it also ensures that the persistence
> > object is cleaned up, even if the
> > delegate() method throws an exception.
> >
> > Craig
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
