Yes, you're absolutely right. The business bean approach is less connected
to the web tier, for better or worse, and does not have to be a Singleton
(didn't think of that one). The framework approach is closer to the web
tier. The two approaches are similar in some respects, but different in
others, and have different consequences in terms of convenience and reuse.
I guess what I really meant is that they are not mutually exclusive. If the
common logic can be cleanly separated from the web tier, then the business
bean approach makes more sense, as it's more reusable. If the logic is tied
to the web tier, then framework approach makes more sense as it's more
convenient to access the web tier. One could use both approaches in the
same app, on a case by case basis.
One question: Do your business beans typically implement the business logic
directly, or do they forward to another existing businesses tier (EJB's,
whatever)? If they forward, then they're kind of like business delegates.
This is the situation I was thinking of when I said the framework and
business bean approaches seemed similar. The business delegate layer might
be somewhat reusable outside a web app, but the real reusable logic would be
in the true business backend that the business delegate forwards to. In
this case, it might partially be a style issue which to use. Putting the
mapping and delegating to the business backend logic in separate business
delegate ('business bean') classes would be a bit more reusable, and more
configurable, but would add another layer. Putting this logic in framework
actions might be a tad more convenient, but slightly less reusable.
This business bean approach sounds really interesting. It sounds like a
business bean is a business tier version of an Action. It has a known
input type, similar to ActionForm, a known return type, similar to
ActionForward, and a known signature, similar to Action.perform. One could
introduce a business tier version of the ActionServlet controller, that
could call business logic validation methods on the input object, manage
transactions, etc. In other words, apply the command and controller
patterns to the business tier. Cool!
Steve Molitor
[EMAIL PROTECTED]
-----Original Message-----
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 9:50 AM
To: Struts Users Mailing List
Subject: Re: [Struts Tips] #2 - Template Method Dispatch Action?
"Molitor, Stephen" wrote:
> The business bean and framework +
> approaches actually seem pretty similar to me. The only difference is
> whether the main extension point is a separate class, or a method of the
> action class. In either case the extension point is specified in the
> configuration file.
I would say that the consequences of the business bean approach include
+ the beans can be reused outside of a web application
+ a bean can be instantiated for every request or could be designed as a
singleton
+ access to web-tier resources is indirect at best
+ business-beans can nest other business beans
Consequences of the framework approach include
+ the framework Action is bound to Struts
+ the framework Action is always a singleton, instantiated once for the
life of the application, and must be thread-safe
+ the framework Action has direct access to web-tier resources
+ forwarding or including other Actions involves outside agents, like
Struts and the container, which may introduce their own behaviours
Others?
"Molitor, Stephen" wrote:
>
> Why are the Framework and Dispatch approaches mutually exclusive? It
seems
> like you could do both -- have a base action with extension points (hot
> spots), and the main hotspot method (i.e. 'executeLogic') could optionally
> be a dispatch method. This would help with create/update/delete
operations,
> where all the logic is the same except for which db operation to perform.
> Of course it's not the only way to do it -- the 'business bean' approach
you
> mention, where the mapping specifies the business class, would also work
> nicely. But the framework + dispatch approach could cut down on the
number
> of classes (business bean or action). The business bean and framework +
> approaches actually seem pretty similar to me. The only difference is
> whether the main extension point is a separate class, or a method of the
> action class. In either case the extension point is specified in the
> configuration file.
>
> Steve Molitor
>
> > I believe the Dispatch and Template (or Framework) class approaches may
> > be mutally exclusive. The idea of the Dispatch class is that you can
> > vector to an arbitrary method. The idea of a Framework class, like
> > SuperAction uses, is that a known entry method calls a number of
> > hotspots (or extension points) that you can override.
>
> -----Original Message-----
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, June 01, 2002 7:31 AM
> To: Struts Users Mailing List
> Subject: Re: [Struts Tips] #2 - Template Method Dispatch Action?
>
> "Molitor, Stephen" wrote:
> > As is, the DispatchAction in Struts 1.02 cool, but does not provide
> direct
> > support for eliminating or consolidating duplicate code from related
> tasks.
> > It's just a different style. With DispatchAction, one can have one big
> > action class to handle related tasks, as opposed to several little
Action
> > classes. However, related tasks often have some common logic that needs
> to
> > be performed for all the tasks, and other logic that is specific to each
> > task. It would be cool if there was a DispatchAction that provided
hooks
> > for the common logic.
>
> For something similar, see the SuperAction in the Scaffold package.
>
>
http://cvs.apache.org/viewcvs/jakarta-struts/contrib/scaffold/src/framework/
> main/org/apache/scaffold/http/SuperAction.java
>
> I believe the Dispatch and Template (or Framework) class approaches may
> be mutally exclusive. The idea of the Dispatch class is that you can
> vector to an arbitrary method. The idea of a Framework class, like
> SuperAction uses, is that a known entry method calls a number of
> hotspots (or extension points) that you can override.
>
> You could share common utility methods among various Dispatch methods by
> passing all needed parameters through the signature, but how to merge
> this idea with a framework class approach isn't jumping out at me.
>
> The closest thing may to be use a relay action to forward the request to
> another Action based on a framework class. You then just override a
> business extension method on the framework Action (like
> SuperAction.ExecuteLogic). This doesn't reduce the number of Actions,
> but it does let you share as much code as possible
>
> Personally, I use very few Struts Actions in an application. Instead I
> tend to specify a business class as part of the action mapping, and then
> have the Action call that, using a base Action like the above. The
> business beans have a hotspot method with a known signature. The Action
> just instantiates the business bean (like the ActionServlet instantiates
> a form bean), calls the signature, and copes with the result. (Just like
> the ActionServlet calls an Action.)
>
> This trades Actions for business beans, but minimizes coupling to Struts
> and maximizes code reuse between platforms.
>
> The Advanced Struts skeleton for Adalon, uses the same approach. (No
> surprise, I wrote it =:)
>
> http://synthis.com/products/architectures/struts/
>
> Synthis has released the skeleton code under the Apache License, and I'm
> integrating it back into the Scaffold package and updating the Artimus
> application to use the new clases. So, there will major updates to these
> next week. All the same ideas, but with some improvements to the
> implementation. Film at 11.
>
> -- Ted Husted, Husted dot Com, Fairport NY US
> -- Developing Java Web Applications with Struts
> -- Tel: +1 585 737-3463
> -- Web: http://husted.com/about/services
>
> "Molitor, Stephen" wrote:
> >
> > As is, the DispatchAction in Struts 1.02 cool, but does not provide
> direct
> > support for eliminating or consolidating duplicate code from related
> tasks.
> > It's just a different style. With DispatchAction, one can have one big
> > action class to handle related tasks, as opposed to several little
Action
> > classes. However, related tasks often have some common logic that needs
> to
> > be performed for all the tasks, and other logic that is specific to each
> > task. It would be cool if there was a DispatchAction that provided
hooks
> > for the common logic. One approach would be to use the Template Method
> > pattern, perhaps something like this:
> >
> > public class TemplateMethodDispatchAction extends DispatchAction {
> >
> > public ActionForward perform(ActionMapping mapping,
> > ActionForm form,
> > HttpServletRequest request,
> > HttpServletResponse response) {
> > beforeHook();
> > ActionForward forward = super.process(mapping, form, request,
> response);
> > return afterHook(forward, mapping, form, request, response);
> > }
> >
> > protected void beforeHook(ActionMapping mapping,
> > ActionForm form,
> > HttpServletRequest request,
> > HttpServletResponse response) {
> > // does nothing by default
> > }
> >
> > protected ActionForward afterHook(ActionForward forward,
> > ActionMapping mapping,
> > ActionForm form,
> > HttpServletRequest request,
> > HttpServletResponse response) {
> > return forward; // just returns the forward that was passed in by
> > default
> > }
> >
> > }
> >
> > Defing the beforeHook and afterHook methods in derived clases would be
> > optional. If you don't define them, TemplateMethodDispatchAction
behaves
> > just like DispatchAction. If you choose to define them, you have slots
to
> > put common pre/post processing logic.
> >
> > The afterHook method returns an ActionForward to allow for cases where
the
> > logic to determine the next page is common for all tasks, and can thus
be
> > coded in one place in the afterHook. However, the default
implementation
> of
> > afterHook just returns the forward returned by the task specific methods
> > (i.e. create, update, delete), to allow for cases where the logic to
> > determine the next page varies with the task.
> >
> > Of course, you can use procedural decomposition to factor out the common
> > logic instead, and rely on the task specific methods (i.e. create,
update,
> > delete) to remember to call the appropriate pre/post processing methods
at
> > the right time. However, the calls to the common methods would still
get
> > duplicated in each task specific method. The Template Method approach
is
> > more automated.
> >
> > Does Struts 1.1 have anything like this?
> >
> > Steve Molitor
> > [EMAIL PROTECTED]
> >
> > -----Original Message-----
> > From: Ted Husted [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, May 31, 2002 6:12 AM
> > To: [EMAIL PROTECTED]
> > Subject: [Struts Tips] #2 - Use DispatchAction to organize related
> > operations
> >
> > Any software application is defined by the things it can do for you. In
> > a Struts Web application, the things an application does is usually
> > defined by its action-mapping elements. An action-mapping is designed to
> > be the target of an HTML form, and is often used with hyperlinks as
> > well.
> >
> > Each action-mapping can specify a Struts Action class as its handler. In
> > larger applications, developers can find themselves managing dozens or
> > even hundreds of Action classes.
> >
> > In practice, many of these Action classes handle related operations,
> > often evidenced by their name. A package might include separate
> > RegCreate, RegSave, and RegDelete Actions, which just perform different
> > operations on the same RegBean object. Since all of these operations are
> > usually handled by the same JSP page, it would be handy to also have
> > them handled by the same Struts Action.
> >
> > A very simple way to do this is to have the submit button modify a field
> > in the form which indicates which operation to perform.
> >
> > <SCRIPT>
> > function set(target) {
> > document.forms[0].dispatch.value=target;
> > }
> > </SCRIPT>
> >
> > <html:hidden property="dispatch" value="error"/>
> > <html:submit onclick="set('save');">SAVE</html:submit>
> > <html:submit onclick="set('create');">SAVE AS NEW</html:submitl>
> > <html:submit onclick="set('delete);">DELETE</html:submit>
> >
> > Then, in the Action you can setup different methods to handle the
> > different operations, and branch to one or the other depending on which
> > value is passed in the dispatch field.
> >
> > String dispatch = myForm.getDispatch();
> >
> > if ("create".equals(dispatch)) { ...
> >
> > if ("save".equals(dispatch)) { ...
> >
> > The Struts Dispatch Action is designed to do exactly the same thing, but
> > without messy branching logic. The base perform method will check a
> > dispatch field for you, and invoke the indicated method. The only catch
> > is that the dispatch methods must use the same signature as perform.
> > This is a very modest requirement, since in practice you usually end up
> > doing that anyway.
> >
> > To convert an Action that was switching on a dispatch field to a
> > DispatchAction, you simply need to create methods like this
> >
> > public ActionForward create(ActionMapping mapping,
> > ActionForm form,
> > HttpServletRequest request,
> > HttpServletResponse response)
> > throws IOException, ServletException { ...
> >
> > public ActionForward save(ActionMapping mapping,
> > ActionForm form,
> > HttpServletRequest request,
> > HttpServletResponse response)
> > throws IOException, ServletException { ...
> >
> > Cool. But do you have to use a property named dispatch? No, you don't.
> > The other step is to specify the name of of the "dispatch" property as
> > the "parameter" property of the action-mapping. So a mapping for our
> > example might look like this:
> >
> > <action
> > path="/reg/dispatch"
> > type="app.reg.RegDispatch"
> > name="regForm"
> > scope="request"
> > validate="true"
> > parameter="dispatch"/> // Which parameter to use
> >
> > If you wanted to use the property "o" instead, as in o=create, you would
> > change the mapping to
> >
> > <action
> > path="/reg/dispatch"
> > type="app.reg.RegDispatch"
> > name="regForm"
> > scope="request"
> > validate="true"
> > parameter="o"/> // Look for o=dispatchMethod
> >
> > Again, very cool. But why use a JavaScript button in the first place?
> > Why not use several buttons named "dispatch" and use the values to
> > specify the operation.
> >
> > You can, but the value of the button is also its label. This means if
> > the page designers want to label the button something different, they
> > have to coordinate with the Action programmer. Worse, localization
> > becomes virtualy impossible.
> >
> > If you prefer not to use JavaScript buttons, you can use the
> > DispatchLookup Action instead. This works much like the DispatchAction,
> > but requires more setup. We'll explore the DispatchLookup Action in Tip
> > #3.
> >
> > HTH, Ted.
> >
> > ---
> >
> > Struts Tips premiere twice weekly on the MVC-Programmers List. To
> > subscribe, visit BaseBean Engineering < http://www.basebeans.com >.
> >
> > An archive of past tips, like this one, is available at <
> > http://jguru.com/faq/subtopic.jsp?topicID=893704 >.
> >
> > About Ted. Ted Husted is an active Struts Committer. He also moderates
> > the Struts mailing list and the JGuru Struts
> > FAQ.
> >
> > Copyright Ted Husted 2002. All rights reserved.
> >
> > _______________________________________________
> > MVC-Programmers mailing list
> > [EMAIL PROTECTED]
> > http://www.basebeans.com:8081/mailman/listinfo/mvc-programmers
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
