struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chappell, Simon P" <Simon.Chapp...@landsend.com>
Subject Layers (was RE: [Book Review] Struts Kick Start)
Date Mon, 23 Dec 2002 14:20:23 GMT
Jacob,

Thanks for the kind words, your check is in the mail! :-)

To discuss the issue a little more here:

I am a great believer in layers. I'm also a great believer in having the right type and number
of layers. This means that I believe it is possible to have not enough layers and it is VERY
possible to have too many layers. I think that some people in their enthusiasm for layers
have added far too many until they smother their program to death. Now that I'm a parent,
I realise that software layers are like blankets on a baby, you need enough to keep them nice
and warm, but not too many or they will suffer and an over-heated baby will scream VERY loud.

Having the right sort of layers is equally important as the number of layers. My rule of thumb,
is that a layer for each fundamental concept is about right. So, if you have some persistence
in your software, you need a persistence layer. We had the concepts of a business service
and a system service in our application, so, guess what, we had a business service layer and
a system service layer.

As for the service layer (I called it an API) I really think that they work. I know that it
worked for us. Think of one of the most common interfaces in your home, the humble electric
socket. That socket is your interface to a service that you want to use. It has type safety
(the funny arrangement of holes), it has a reusable interface that lets you use your vacuum
cleaner one minute and your computer the next if you desire. A service (API) layer does the
same for you. On my most recent completed project, we were not certain that the Web interface
was going to work well in a high-transaction, on-demand system in a warehouse, so the API
gave us the clear demarcation between business logic and presentation. If we ever need to
put a Swing style GUI on the system, it won't be too frightening (well, no more frightening
that any other Swing GUI).

I hope that something in this tome has helped. Feel free to ask if you want any more detail.
Also, check out the PowerPoint slides for the presentation that Jacob mentioned, they are
available from the struts page on my website at:

http://simonpeter.com/techie/java/struts/index.html

Simon

-----------------------------------------------------------------
Simon P. Chappell                     simon.chappell@landsend.com
Java Programming Specialist                      www.landsend.com
Lands' End, Inc.                                   (608) 935-4526


>-----Original Message-----
>From: Jacob Hookom [mailto:hookomjj@uwec.edu]
>Sent: Friday, December 20, 2002 6:38 PM
>To: 'Struts Users Mailing List'; jerome.jacobsen@gentootech.com
>Subject: RE: [Book Review] Struts Kick Start
>
>
>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 ;-)
>
>Regards,
>Jacob Hookom
>UWEC Computer Science
>
>-----Original Message-----
>From: Jerome Jacobsen [mailto:jerome.jacobsen@gentootech.com] 
>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 [mailto:Simon.Chappell@landsend.com]
>>
>> 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
>application.
>
>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:
><mailto:struts-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail:
><mailto:struts-user-help@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail:   
<mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message