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 RE: Architecture advice....
Date Mon, 29 Jul 2002 19:27:34 GMT
Not yet! Of course, the API methods are 100% passthrough. They exist only to prevent "M" mixing
with the "V" and "C". To that extent, I am not too worried.

Simon

>-----Original Message-----
>From: Michael Delamere [mailto:home@michael-delamere.de]
>Sent: Monday, July 29, 2002 2:30 PM
>To: Struts Users Mailing List
>Subject: Re: Architecture advice....
>
>
>Thanks to you also!
>
>It´s a great help to hear other peoples experiences.  What we 
>were worried
>about is that all calls for a particular job would go via the 
>one and only
>static method; i.e. thought it might become a bit of a 
>bottleneck.  Did you
>experience anything along those lines?
>
>Thanks for your time.
>
>Regards,
>
>Michael
>
>
>----- Original Message -----
>From: "Chappell, Simon P" <Simon.Chappell@landsend.com>
>To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
>Sent: Monday, July 29, 2002 9:06 PM
>Subject: RE: Architecture advice....
>
>
>> Well, what we did to seperate Struts from the backend was to 
>implement
>what we called a "Firebreak". We created an abstract Java class called
>API.java. It's whole purpose in life was to be the application 
>API to the
>model component. This would enable us to utilise  alternative 
>views and/or
>controllers if our needs ever took us in that direction.
>>
>> All functionality in the application is accessable through 
>static methods
>in the API class. This is nice for us, we removed all 
>processing logic from
>the actions and put it in the main application space. Now our actions
>concentrate on ActionForms and calling the API methods.
>>
>> To further the break between view and logic, we use Request and Reply
>objects to carry the data on the calls into and the return 
>values back from
>the API.
>>
>> Simon
>>
>> -----------------------------------------------------------------
>> Simon P. Chappell                     simon.chappell@landsend.com
>> Java Programming Specialist                      www.landsend.com
>> Lands' End, Inc.                                   (608) 935-4526
>>
>>
>> >-----Original Message-----
>> >From: Michael Delamere [mailto:home@michael-delamere.de]
>> >Sent: Monday, July 29, 2002 1:15 PM
>> >To: Struts Users Mailing List
>> >Subject: Architecture advice....
>> >
>> >
>> >Hi,
>> >
>> >I had a discussion at work today concerning the best way to
>> >implement our
>> >application.  A very
>> >basic discription of the framework would be the following:
>> >
>> >1. Struts + Velocity for the view
>> >2. Struts ActionServlets for the controller
>> >3. Service layer/methods for querying persistence layer
>> >4. OJB persistence layer
>> >
>> >The main debate was actually about what the service layer
>> >would look like.
>> >We thought about the following options:
>> >
>> >1. The service layer consists of static methods
>> >2. The service layer would consists of normal classes
>> >3. The service layer could consist of servlets
>> >
>> >The idea is that (this is nothing new of course) the service
>> >layer would
>> >purely have methods such as addToShoppingBasket() or
>> >checkLogin(); basically
>> >service methods which carry out the communication with the
>> >persistense layer
>> >and returns the result to the controller.
>> >
>> >The question is though, should we create a new object every
>> >time we want to
>> >access a stateless method?  Surely that would be a bit of an
>> >overhead.  Go
>> >with servlets?  This possibly ties it to the web-container 
>too much and
>> >isn´t very elegant (?).  Another option would be just to use
>> >static methods;
>> >can this cause a problem when wanting to distribute to more
>> >than one server?
>> >Is it better in terms of performance?
>> >
>> >I would really appreciate some help and ideas on this.  It
>> >would make things
>> >easier in terms of deciding on the next step.
>> >
>> >Thanks in advance!
>> >
>> >Regards,
>> >
>> >Michael
>> >
>> >
>> >--
>> >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>


--
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