Yep, services should be singletons, should be "mostly" stateless, and since they're singletons almost have to be cached. I say "mostly", because there is often some state that the object needs to maintain, but it's not really "object state". Stuff like DSNs, or directory paths. Not really part of what it means to be a service, but still essential data that the service needs to operate.
I'm not familar with the service locator pattern, but this page http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html seems to indicate it has nothing to do with the caching and such. All that stuff should happen in the service factory; the locator is just a means of finding the factory. The locater pattern seems to be for scenarios where you don't have an explicit reference to the factory available already (as is often the case in large J2EE apps that use JNDI), but doesn't really apply to CF, since you've got the application scope. cheers, barneyb On 9/26/05, Ryan Guill <[EMAIL PROTECTED]> wrote: > Well the reason I am interested is because COAL was intended to be a > good example of the service locator pattern. One of the parts (a big > part) of the service locator pattern though is the caching of objects, > so that if you request the same object (or service) over and over > again that it would hold a copy and save you some cycles. and now > that I am writing this its starting to make more sense that it is the > "service" locator pattern, and a service is stateless, so it wouldnt > matter if it was cached, it should be cached, its a singleton! damn. > > well, while the other part of the service locator pattern works very > well for COAL, the caching part of it (it was designed to be cached > before instantiation, so that you could pull a "fresh" copy out and > isntantiate it again and go, it just would just save the > createObject()...) is basically worthless in this situation. I had a > sneaky suspicion of this for a while and just haven't found the time > to test it out. Guess this answers it. > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
