I agree Chris and had the same conversation with Sean. I still say encapsulating access to the session scope into one CFC is better than accessing the session scope directly because you do have SOME control over what they can do and have the ability to modify the implementation if necessary without changing the code using the Facade. However, he won me over with the argument that it's too easy for developers of different service layer components to try to take "shortcuts" and get at session data they really shouldn't have access to via the facade, rather than going through the "proper channels" and calling other services. Even though disciplined developers wouldn't succumb to the short cut temptation, (hopefully!), it is a very valid point and one that can't be refuted. So basically he's beat me out of my bad habit (and now he has the fun job of continuing the discussion to explain it to everyone else hehe).
On Nov 5, 2007 10:58 PM, Chris Scott <[EMAIL PROTECTED]> wrote: > WOW this list is SLOW! Takes about 24 hours for a post / response, we > need to fix this! But back to the posts... > > >> or 'getValue(key)' (along with accompanying setters. Inside these > > > > ...that would mean any service component that has access to the facade > > could access *any* session variable! That totally defeats > > encapsulation - you might just as well refer to session scope > > directly. > > I didn't necessarily say I was suggesting best practices, I'm just > trying to help and explain the concept of a SessionFacade in general. > However, even with such an implementation, I am not sure I would say > you may as well refer to the session scope directly. I DO advocate > building domain specific methods in a session facade such as > getCurrentUser(), but I am not sure I would 100% remove the semantics > of the user existing in the session from other components. Delegating > session access to a separate component provides valuable de-coupling > and the ability to mock the session easily for unit tests. Completely > protecting model components from the session, or vica versa, by > totally separating them is excellent, but I cannot say I fully agree > that opening up session access via a facade is so terrible. It really > depends on who you are protecting your code from. There are tons of > developers out there working on small teams that really don't need to > be going crazy trying to protect their code against themselves. Larger > projects, larger teams may very well set different standards, but I > would absolutely hate to see everyone jump up in arms declaring that > we should never ever access session from model components under any > circumstances. > > > Chris Scott > [EMAIL PROTECTED] > http://cdscott.blogspot.com/ > http://www.coldspringframework.org/ > > > > > > > > > > On Nov 4, 2007, at 11:57 PM, Sean Corfield wrote: > > > On 11/4/07, Chris Scott <[EMAIL PROTECTED]> wrote: > >> What Sean is suggesting as a 'UserService' can be thought of a a > >> SessionFacade. This is an object that you use to encapsulate all > >> access to the Session, and can provide methods like > >> 'getCurrentUser()' > > > > But I do *not* advocate a single generic session facade - I am very, > > very adamantly opposed to that approach because it totally breaks > > encapsulation: > > > >> or 'getValue(key)' (along with accompanying setters. Inside these > > > > ...that would mean any service component that has access to the facade > > could access *any* session variable! That totally defeats > > encapsulation - you might just as well refer to session scope > > directly. > > > > What I am suggesting is a service component that deals with user > > objects and as *part* of that role, it encapsulates how an individual > > user object is managed in memory. It may be held in session scope or > > it could be managed by a cookie (containing the user ID and you fetch > > the user details from the database as needed) or whatever. > > -- > > 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 > > > > >
