Saving Session Data
So, I'm cruising around the blogsphere today and I happen to come across this this post by Rory. (Actually I didn't stumble across it, I subscribe to his RSS feed, but don't tell him that. He might get an ego or something. :) ) Rory makes reference to a post written by Steve Maine. Go read it, then come back.
Okay, here's the deal. I like the fact that Steve's post removes unnecessary string literals from code (string literals are Magic Numbers' younger, less ugly sister), but I don't think that his methods give as great of speed improvements as he is talking about.
Lets take his example:
newOrder.CreditCard = (CreditCardInfo)HttpContext.Current.Session[CREDITCARD_KEY];
newOrder.BillingAddress = (AddressInfo)HttpContext.Current.Session[BILLING_KEY];
newOrder.ShippingAddress = (AddressInfo)HttpContext.Current.Session[SHIPPING_KEY];
He wants the above changed to read something like the following:
SessionDataContainer sessionState = HttpContext.Current.Session[ CONTAINER KEY ];
newOrder.CreditCard = sessionState.CREDITCARD;
newOrder.BillingAddress = sessionState.BILLING;
newOrder.ShippingAddress = sessionState.SHIPPING;
Comparing the two snippets of code, I definitely prefer the latter. If you ever ask anybody I have ever worked with, they will tell you how much I hate magic numbers. (Steve needs to run his code through FxCop though. Public member variables? All uppercase variable names?)
For code maintainability the above solution is great. The problem I have is that Steve is assuming in-process session management. With out-of-process session management instead of having 3 objects that you can access randomly when you need them, you now have one larger object that needs to be serialized and deserialized. Let's say that I only need the shipping address. Why should I need to deserialize the credit card and billing address objects? That is a huge performance hit! Whatever gains in speed you had before you have just completely annihilated by moving to out-of-process memory management.
If you are looking to solve some maintainability issues, Steve's post is a brilliant way to make source code cleaner. If your looking to speed up your code, I don't think you will gain incredible amounts of speed by adding a strongly typed container to your session lookups.
Comments
Rory on on 11.25.2003 at 1:47 AM
"He might get an ego or something."
Too late, my friend :) Way, way, way too late...
"The problem I have is that Steve is assuming in-process session management. With out-of-process session management instead of having 3 objects that you can access randomly when you need them, you now have one larger object that needs to be serialized and deserialized."
I totally agree here. This problem had occurred to me, but Steve's idea is still pretty snazzy for in-proc stuff.
For anything else, I've already gotten in the habit of creating a centralized session state manager (mainly just properties that act as middlemen between me and the objects I'm stuffing in the session object). However, I had just never gone the extra step to do what Steve suggested.
And, done right, it'd be possible to swap out Steve's system for one which would make much more sense when using an external session state store without having to change the interface to the objects being stored.
That sentence doesn't make much sense, but I stand by it, mainly because I don't want to rewrite it.
Anyway, you've brought up a good point.
Well said, mister.