Karl Seguin

.NET From Ottawa, Ontario - http://twitter.com/karlseguin/

Best of both worlds - SessionCache

A while ago, Sonu of DotNetSlackers asked if I'd be interested in writing for the site. I've been a long time fan of what DotNetSlackers stood for (trying to bring some order to this vast community of ours), so I was more than happy to oblige.

I'm a huge fan of .NET's cache. I can't think of many good reasons to use either the Application or Session objects, rather than the Cache object. Two things that I've always wanted from the cache is (a) per-item control over where the data is stored and (b) per-session cache.

Best of both worlds - SessionCache is my brief article on how to achieve a reusable and clean solution to (b). It isn't anything fancy, but I thought it might be of some use.

Feedback is always welcomed.

P.S. - I know Sonu has to pay the bills, but IntelliTxt really sucks :)

Published Nov 06 2006, 11:54 AM by karl

Filed under: Short Outbursts

Comments

Brendan Tompkins said:

Very cool article Karl!

# November 6, 2006 2:56 PM

Sonu Kapoor said:

Thanks for the kind words and the contribution to DotNetSlackers Karl.

# November 6, 2006 3:13 PM

Dror Engel said:

Hi Karl,

very nice article, I really enjoy to read it

Dror.

# November 6, 2006 11:20 PM

SirMike said:

Quite nice article but I don't understand default constructor of SessionCache class.

Why do you check if HttpContext.Current is null and if it is you assign uniqueId with random GUID? Every instance of this class outside HttpContext will have different key - it's rather useless. Maybe I don't get it, can you explain?

# November 7, 2006 3:04 AM

karl said:

Mike:

You are right. Using the default constructor outside of an HttpContext will result in a uniqueId for each instance of the class. The goal is to let the implementor hold on to each instance per-user however they see fit. It's typically much easier for non web-apps to hold on to references over the course of a "session".

In other words, it becomes up to the implementor to ensure that one and only one SessionCache is created per user and that reference is kept around until the user shuts down.

A comment to identify this would help greatly!

Generally, I'd opt for the overload where you can specify your own uniqueId.

# November 7, 2006 6:37 AM

Joey Chömpff said:

Two years ago I wrote something similar.

# November 20, 2006 3:30 AM

worlds best suck jobs said:

Pingback from worlds best suck jobs

# April 19, 2008 6:09 PM

Name (required)

Your URL (optional)

Comments (required)

Remember Me?

Enter the numbers above:

Add

About karl

I'm a developer living in Ottawa, Ontario. I like to focus on medium to large scale enterprise development, maintainable code, DDD and unit testing. I occasionally speak at conferences, am an editor for DotNetSlackers and contribute to projects here and there.