Well, summer is over and I’m back home now…classes start back today…well, meetings about classes start at least.  The internship experience I had over the past few months was great and I am really looking forward to using the new knowledge this semester – especially with the MIS project team (I’ll post more about this in a day or so).  It looks like this semester classes are just going to be on Tues & Thurs which is great…granted, that means Tues & Thurs are pretty much shot for the whole semester, but I’d rather do that than have one or two classes every day of the week (except Friday – the business school doesn’t have classes on Friday…every other part of campus does, but somehow the business classes always work around that.)  This semester should have some pretty interesting challenges in several different areas.  I’m hoping to be able to get INETA started here this semester, get more visitors to my ticket exchange website (www.bamatrader.com – if you’re looking for Alabama tickets, check it out 😉 ), and then a couple of little side projects that I’ll talk about in the future…in addition to the regular course load.  Anyway, time for the first meeting of the day…more to come.

Until this summer, I didn’t see anything wrong with putting something in the Session object by saying:
 
Session[“Something”] = MyVar;

Of course, that’s a perfectly legal way to use the Session object and it works quite well.  So what’s the problem?

Well, let me give you an example of why this can be bad.  On one of the big projects I’m working on this summer, we use the Session object to store GUID values which are the keys to tons of things in the system (e.g. you use this GUID to look things up in about 20 different tables).  What we’re building is basically a massive ASP.NET-based wizard for doing some business tasks.  So it’s quite critical that this GUID is passed between pages in a way that each of them can understand.  Well, the situation has now come up that some people started putting the GUID in Session[“GUID”] (which is right) but as a string instead of a GUID object.  I, on the other hand, am storing my GUIDs in the same Session location, but I’m storing the real GUID object. 

Because you can’t cast a string into a Guid, we have to have two sets of code to convert Session[“GUID”] back into a Guid.  Now you can solve this problem by having standards and enforcing them, but that still leaves room for people to make mistakes and still get it wrong.  After having to deal with this issue for a couple of days (we’re still trying to find every place that sets these Guids so they can be standardized), I am really thinking making a wrapper for your Session objects would be a good idea.  Using the wrapper idea on the project I’m currenting working on, I would have a property of type Guid that will still set and get the Session[“GUID”] object, but it will be the only way to get a Guid in or out of the session…this way, it doesn’t matter if it’s stored as a Guid or string – you’re code never knows.  And you don’t have the problem of people storing the same thing in multiple places (or at least it would help with that). 

I know this is all fairly obvious stuff, but wrappers (for stuff like this) and all the people wanting strongly-typed collections didn’t really make a lot of sense to me until this summer.  Of course, I saw the benefit it added, but I didn’t realize why that was so important, but I certainly know now and in the future, my code is going to look quite different.