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:[EMAIL PROTECTED]] >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" <[EMAIL PROTECTED]> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >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 [EMAIL PROTECTED] >> Java Programming Specialist www.landsend.com >> Lands' End, Inc. (608) 935-4526 >> >> >> >-----Original Message----- >> >From: Michael Delamere [mailto:[EMAIL PROTECTED]] >> >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->[EMAIL PROTECTED]> >> >For >> >additional commands, >> >e-mail: <mailto:[EMAIL PROTECTED]> >> > >> > >> >> -- >> To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> >> > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
