Hi, I have designed our service layer using normal classes, I initialize the service layer on application start up and place them in the ServletContext. I have been looking at this strategy and considering using Static methods as well, as the only state in these classes is the jdbc driver and base data source. My persistency layer implementation handles concurrency issues and I don't think I would run into any issues having the application distributed to more than one server.
Wish I could offer more help, but I am in the same boat. Greg -----Original Message----- From: Michael Delamere [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 2: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:[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]>
