I'm happy to hear of Sean's disdain for session facades. I've looked at the pattern for a while now, just scratching my head. It seems to me that with the same amount of discipline one would exert using a session facade, they could directly access the session with less effort and fewer lines of code.
If you have a session facade object, chances are it lives in your service layer, which is where any and all direct access to your session would go as well. This, to me, is one pattern that shouldn't be carried over from the Java world, where the primary reason is to make access to the session easier (the reason for any facade). In CF, it's already too easy. Are we trying to make it harder? -- nathan strutz http://www.dopefly.com/ On 11/4/07, Sean Corfield <[EMAIL PROTECTED]> wrote: > > On 11/4/07, Justin Judd <[EMAIL PROTECTED]> wrote: > > I believe in the example it is the role of the UserService to > encapsulate > > the session mechanism itself (serving as a Session Facade). Something > has > > to know about how sessions are handled in the application and that is > the > > purpose of the UserService so it's okay for it to access the session > scope. > > The idea is if the session mechanism were to change for some reason, you > > > would (theoretically) only have to make the changes in one place (the > > UserService) and the rest of the application wouldn't know or care about > the > > change. This design decision means the session scope becomes an > internal > > concern for the UserService; it doesn't get passed in because no other > > object even knows about the session. The UserService can access the > session > > directly, so it doesn't need to get that information anywhere else. > > Yup. What Justin said. > > > If it were the case that no CFC can ever access a shared scope, you > wouldn't > > ever be able to use shared scopes in an application. You definitely > want to > > minimize the number of CFCs that access shared scopes (and thus are > affected > > by any changes you make to those scopes), so you build a single CFC that > is > > responsible for that access and inject this "Facade" CFC into your other > > CFCs that are interested in that scope. > > I think that's an unnecessary overhead and, as I've said at length on > several lists now, having a single SessionFacade CFC doesn't actually > add to the encapsulation (if it allows access to any session scope > data it actually *breaks* encapsulation). It's far more practical to > have the few services that need to manage data in a shared scope > actually do so directly, just isolating it to a single method that > creates the bean on demand in the shared scope if necessary. > > Brian (Kotek) argued that having a specific facade for each service > solves the broad access issue and, whilst I agree, I think that just > adds another class for no real benefit. He argued it improved > testability but you can easily test a service that isolates shared > scope access to a single method by creating a test service that simply > extends the original service and overriding just the one method. My > principle is: don't over-complicate your application design just to > make testing easier. Of course, you need to ensure that your > application is testable *somehow* but pain for the test cases is > better than pain for maintenance of the application in general. > -- > Sean A Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > >
