struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pilgrim, Peter" <>
Subject RE: [OT] Business Layer Ideas
Date Tue, 31 May 2005 13:33:02 GMT
> -----Original Message-----
> From: Dakota Jack []
> I should have added that Rod (Johnson) in the book cited pointedly
> advocates extensive use of the Strategy Pattern, see pp. 421 ff.  The
> use of CoR in Struts 1.3 for the extensible RequestProcessor is not a
> feature but is a way of solving the problem created by the original
> use of the Template Method Pattern in that context.  Had the Strategy
> Pattern been used in the first instance, everything would have worked
> better, in my opinion.  In many ways, I think in the future the
> Template Method Pattern may be seen as an Anti-Pattern.
> Just to forestall flamethrowers, I want to emphasize that others
> probably think differently and even the "majority", i.e. by definition
> the members ipsa facto of the "meritocracy", may think differently. 
> But, Rod Johnson is no slouch on these matters.  He thinks the use of
> Strategy Pattern is "one of the reasons [Spring] is such a flexible
> and extensible framework".

Hello Jack

It can be shown that ``Chain of Responsibility'' pattern can be 
metamorphed into the ``Strategy'' pattern. The first proviso is that one
of your commnds becomes a catalogy factory or invoker of other
generic commands itself. The second proviso is you must pass all
your information back and forward the ``strategy command'' using
a general context object.


> On 5/27/05, David Whipple <> wrote:
> > This is an off topic post, but there seem to be a lot of 
> people with good
> > opinions here.
> > 
> > I am trying to provide a framework (based on Stuts and 
> Spring) for our
> > company
> > to use.  I'd like to make a reinforcement of the business layer in
> > applications.
> > 
> > We do not use EJBs, so a lot of the patterns that are out 
> there do not seem
> > to
> > apply.  I have not been able to find any references I like.
> > 
> > The goal is to encourage better program design and development by
> > having a clear definition of what are the business objects 
> in the program.
> > 
> > We want to come up with a way through patterns to help 
> programmers avoid
> > poor
> > programming practices.  Clear separation into layers is one 
> basic idea
> > behind
> > this.  We want to come up with some interface to the 
> business layer which
> > will
> > force programmers to know what are to be the business 
> objects in their
> > architecture.
> > 
> > Does anyone have any ideas and/or know of any references for this?
> > 
> > Thanks,
> > Dave


Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497

This message is for the sole use of the intended recipient. If you received 
this message in error please delete it and notify us. If this message was 
misdirected, Credit Suisse, its subsidiaries and affiliates (CS) do not 
waive any confidentiality or privilege. CS retains and monitors electronic 
communications sent through its network. Instructions transmitted over this
system are not binding on CS until they are confirmed by us. Message 
transmission is not guaranteed to be secure. 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message