ColdFusion and the Session Facade
posted under category: ColdFusion on December 14, 2008 by Nathan
We've heard it, we may have seen it in action. If you have ever asked yourself "why," this is for you.
(BTW, I'm just going to call it a "facade" because "façade" is too difficult for my keyboard to produce)
The Pattern
A facade is a fake front, like a mask. A session facade hides away the "complexity" of using a session.
The session facade is the point-of-contact for your session variables. Using one, we no longer have a session scope that you can talk to, now we talk to the facade. The facade offers basic bean methods with generic names - get(), set() and delete(), or a variation on the theme.
Dave Ross has pretty much the definitive ColdFusion Session Facade article (2 pages worth and sample code) - how to use it and all. I'm just considering the usefulness of it.
That sucks
Instead of #session.username#, now we can just type #application.objectFactory.getBean('sessionFacade').getData('username')# and the session facade will handle the dirty work of typing the scope name "session" for us. Finally, more typing!
So now that we're typing more, we also have to learn a new API for managing the session scope. What if we use get, put and delete methods and our friend Bob Bobbery uses get, set, remove, clear, search, etc, etc? More to learn equals more complexity.
And what problem exactly did this fix? We had a session scope before, and we technically still have it. Nothing forces the bad coders on our eam to use it. Nothing really changes, assuming the facade just gets and sets variables from the session scope. It just added another CFC to manage and a bunch of extra code.
The final problem is that the session facade doesn't do anything to manage the session, to organize it, report on it, fix problems that could occur or reduce complexity. It's typically just a dumb bean with variables.* replaced with session.*. It's useless.
Oh, that might be cool
We programmers are managing change. That's one of the things that we do, and hopefully, we will do it well. What if the session scope goes away... no not likely, but with a session facade, we have the mechanism to manage every variable in and out of the session scope. We could reroute it to a database.
The session scope could disappear due to an administrative switch. On a hosted server, we may have no choice. The session facade could then be changed to get essential data from the database at every request.
What if, to reduce server memory, we want to put certain variables, or certain types of variables in our database. The session facade could be made to leave some things on disk, some in memory. A little brains can be added without touching the rest of the application.
What if we want to write a log event every time something goes in and out of the session scope? The session facade is basically our only option for this. The only other way would be to search our code for the word 'session' and add a cflog on each event. With a session facade object, we can do logging or any other type of thing all in one place. Not bad.
Perhaps we may want to cflock each session access because of some potentially unsafe code reading and writing to one variable - we can do that easily here by exclusively locking the set method and readonly locking the get method, using a unique session key to name the lock.
In summary
In summary, the choice to use a session facade should be based on the risk of drastic session scope change. The benefits seem to be a lot of 'what if' scenarios, but they could happen, maybe, while the drawbacks seem to pay off right away. Laziness now or laziness later?