I'm curious, then, how you handle reference to the session scope in your service. Do you actually reference the session scope directly? One of the things I like about the centralized SessionFacade is that it is easy to test by feeding in a "fake" struct that the facade uses in place of a real session scope.
On Oct 30, 2007 12:37 AM, Sean Corfield <[EMAIL PROTECTED]> wrote: > On 10/29/07, Brian Kotek <[EMAIL PROTECTED]> wrote: > > And since I have never run into a situation where different > > services needed to use different persistence mechanisms > > I have. One day you will too. But again, doesn't my approach make it very easy to refactor and supply an alternate shared scope interface component to the service if that should ever be necessary? > <peeve>And it's not "persistence" - memory is not persistent by > definition, disk-based systems are persistent.</peeve> I knew you'd say that which is why I was fumbling with the label to use. ;-) I'm still used to the days when we called these "persistent scopes". > > > If one had direct references to the SessionFacade all over their code, > I'd > > agree with you. > > Which is what most people do and that's why I'm making a fuss! > > I'm reviewing an application right now that has a sessionFacade > containing nearly 80 methods for all sorts of random stuff and > consequently they have references to sessionFacade all over their > code. Clearly that is a pretty poorly thought out design. > If you're using it as a simple get/set facade and injecting it > directly into your services and then only using it within one or two > methods, that addresses part of my complaint but now you've created an > artificial coupling between classes - your services all become > dependent on the facade and are all tied to the same shared scope > handling. You've introduced an extra layer of abstraction for no real > benefit - the service still refer to "session" (as the name of a > component); you've introduced a (slight) performance overhead and you > no longer have granular control over how the data is stored. The extra layer of abstraction does make it easier to test, as well as know where I need to go look for any code that has anything to do with a shared scope. If the name is really bothering you I can refer to it as SharedScopeFacade or something similar. I just call it SessionFacade because, as a label, everyone pretty much understands the concept of a session as data that exists across multiple user requests. In other words, I see a difference between SessionFacade (the concept) and, say SessionScopeFacade (explicitly stating what scope is being encapsulated). > There is a trade off here (of course) and I'll argue that having a > single method inside a service that encapsulates use of session scope > is better encapsulation than having the service depend on an external > class that lots of other components also depend on. I agree that there is a trade off, and I hope that given this and the previous post that, while you wouldn't take the same approach, that the approach I'm using is: superior to direct references to the session scope across your code; superior to the generic all-in-one session facade that uses one get and one set method; and superior to the usage of a centralized SessionFacade that is also referenced all over the code instead of only within services (and even then to a very limited degree). In other words, the disagreement between our two approaches has actually been narrowed down to a single specific issue (the single facade vs. separate interaction with a shared scope within each service). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Create robust enterprise, web RIAs. Upgrade to ColdFusion 8 and integrate with Adobe Flex http://www.adobe.com/products/coldfusion/flex2/?sdid=RVJP Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:292306 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
