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
