Robert
Comands are really a good Solution for acting on business logic. See the common-chain framework also. It offers command and chains to access the business logic in different manner.
Manfred
Robert Taylor wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
