struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jerome Jacobsen" <>
Subject RE: [Book Review] Struts Kick Start
Date Fri, 20 Dec 2002 21:35:01 GMT
> -----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 design
that has been bugging me recently.

So you shouldn't use the business objects in the Actions.  What should you
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 very
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 feeling
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 up
doing the same things to the Domain Model.  If you leave it out and end up
needing to support a non-Struts framework *whose controllers do nearly the
same things as your Struts Actions* then refactor a Service Layer into your

But I think front-ends can differ significantly in their Domain Model usage.
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 the
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 speaking
from experience here since I've only done Struts apps where the only clients
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.  I
just don't see it yet.

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

View raw message