struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacob Hookom" <>
Subject RE: [Book Review] Struts Kick Start
Date Sat, 21 Dec 2002 00:38:26 GMT
We actually had Simon come as a guest speaker for our Seminar series on
campus where he went into great detail of his service layer.

I decided to implement the service layer on my final project for the
semester (a fairly straight forward evaluation system for courses).
Without any modification to the business layer I was able to implement
both a Swing and Struts presentation layer because of an intermediate
Service Layer.

In addition, because of the Service Layer, the business layer could be
switched from strict XML to a relational DB system without changing any
of the presentation level.  Another nice feature is that you can then
have a mixed business layer, different caching techniques and different
persistence layers, again, while not modifying the presentation layer
because everything is accessed through the Service or Integration layer.

In the larger scope of things, let's say we needed to generate a list of
all service providers for a given area; this feature is used often and
seems to be taxing on the server with every request.  Without an
integration layer, we have to modify each Action that pulls that data
in.  But if we are pulling that data from a Service Layer, we can add
some caching feature to the Service layer possibly just modify a single
method, unknown to the presentation layer.

We can still stick to the Bridge pattern with the Service Layer to allow
presentation layer components to directly access the business layer, but
if at all possible, the requests for BO's should be handled by the
Service layer to allow swapping of persistence logic later without
changing the presentation layer.

Simon probably has more info, but I think the integration/service layer
is the bombz.  Truth be told, most any addition of a layer is good ;-)

Jacob Hookom
UWEC Computer Science

-----Original Message-----
From: Jerome Jacobsen [] 
Sent: Friday, December 20, 2002 3:35 PM
To: Struts Users Mailing List
Subject: RE: [Book Review] Struts Kick Start

> -----Original Message-----
> From: Chappell, Simon P []
> What's not so good?
> Just one niggle, and it's more of a programming style issue, but
> in their example code they have references to their business
> objects. They explain that it is important to separate out
> business logic from action logic, which it is, but then proceed
> to use their business object within the action.
> Now, I realise that example code is not the same thing as robust,
> production-ready code, but when people are first learning a
> language or framework, they tend to copy exactly what they see in
> the book they are learning from. Even though example code should
> be light on error checking, it should be heavy on correctness and
> good style.

This is not a critique of your critique, but more of a question on
that has been bugging me recently.

So you shouldn't use the business objects in the Actions.  What should
do instead?  Create a Service Layer as described in Fowlers new patterns
book?  If I remember correctly Fowler says he doesn't use this pattern
much.  He accesses the Domain Model from the controller (in Struts the
Action).  Now it may be that what one designer puts in a Service Layer
Fowler instead puts in the Domain Model.  I dunno.

I'm torn on whether to use the Service Layer approach.  My current
is to leave it out unless it adds value initially.  It would add value
initially if you have multiple font-end frameworks whose controllers end
doing the same things to the Domain Model.  If you leave it out and end
needing to support a non-Struts framework *whose controllers do nearly
same things as your Struts Actions* then refactor a Service Layer into

But I think front-ends can differ significantly in their Domain Model
A web front end for a palmpilot or cell phone would result in a lot of
Actions being called relative to a desktop browser client.  It would use
Domain Model differently than the desktop browser case.  Therefore the
Service Layer would provide little value.  A Swing client may have very
different usage patterns too because of the statefullness.  I'm not
from experience here since I've only done Struts apps where the only
were desktop browsers.

I think that defining the service layer without having multiple clients
*with similar usage patterns* may end up being a big waste of time and
effort and you may get it wrong anyway.

Any other thoughts?  I'm happy to be proven wrong and to see the light.
just don't see it yet.

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

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

View raw message