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/
<<inline: TeamFusionD.gif>>
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 allaccess 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
