I chose not to implement a session facade in my current project but have done it this way in other applications. I really dislike bunches of static method calls so this solution works nicely. I mispoke when I mentioned the factory method; it would only create the singleton instance on the first request, after that it would always return that instance. You would use your service layer like this:
// returns same instance every time ServiceFacade sf = ServiceFacade.getInstance(); sf.doSomeServiceMethod(); instead of ServiceFacade.doSomeServiceMethod(); Sure, it's one more line of code but it is a cleaner design to me. >Yep, thatīs exactly what it sounds like :-). I would like to implement >something similar to the session facade used in EJB environments. > >I like the singleton idea. Have you implemented this yourself. What are >your experiences in doing it this way? >I take it that the factory would do the job of making sure that only the >existing instance is returned and if gone, create a new one. > >Have I got that right? I certainly like the idea. > >Regards, > >Michael > > >----- Original Message ----- >From: "David Graham" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Monday, July 29, 2002 8:59 PM >Subject: Re: Architecture advice.... > > > > Sounds like a "how to implement a facade" problem. I would make your > > service layer a singleton with a factory method to retrieve the >instance. > > That way you avoid the static method calls and maintain the symantics of > > passing messages to objects (the singleton). You also avoid creating a >new > > object everytime you want to use a service method. > > > > > > >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]> > > > > > > > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > > > -- > > 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]> _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
