Brian Kotek recently wrote on the fusebox5 list a short discussion on using session facades. In short you're making a component to encapsulate gets and sets to the session structure. Why do this? Well, it turns out that there are two good really reasons: his and mine.
First, as Brian points out during request initialization you'd typically pass in a session structure for it to use. However, for testing purposes, you can create your own "session" structure with test values for edge cases and pass that in instead. Read his discussion for more on that.
The second reason, and to my mind a better one, is that you can also, in addition to the session and test structures, pass in a CLIENT structure when you initialize the facade. (Or write a polymorphic version that's client based and not session based.) This can make your code a lot more portable, as then the rest of your code doesn't care if one site is using session variables and another is using client variables. Both simply talk to the facade that manages those resources.
You can also, if need be, add a safety check to the "setter" function that makes sure everything passed in is a simple variable and not a struct or query, as the client variable system don't support serializing non-simple types to the database.
(Putting queries into a session is a bad idea anyway, as it can impact site scalability.)
BTW, in design pattern terminology a facade is simply a name for an object that provides a simplified interface to a larger body of code. It can also, as we see here, reduce dependencies of outside code on the inner workings of a library or system, and can allow the "back end" to change without impacting the systems that use it.
Comments