Scott Hanselman's Computer Zen - Using the ASP.NET Cache outside of ASP.NET

« SlickRun and QuickSilver | Main | 20% off Acronis TrueImage »

Using the ASP.NET Cache outside of ASP.NET

Posted 2005-11-23 07:31 AM in ASP.NET | NUnit.

Travis was talking about using the ASP.NET Cache object/subsystem outside of ASP.NET. I found it a little creepy as I've had all sorts of trouble trying to to Mock testing with ASP.NET outside of IIS and ended up using Cassini back in the day.

He convinced me though, check out the sample code on his site. I also started a conversation on a list server and here's what came of that:

Rob Howard said:

Yes, it's fairly common (and easy) to do. You just have to include a reference to the System.Web assembly in non-web applications; which may have led to your "creep out" – for what it’s worth it used to do the same to me :)
FWIW, I believe (from memory) the recommended way you grab a reference outside of a web application is:
using System.Web;
using System.Web.Caching;
…
Cache cache = HttpRuntime.Cache;
<snip>...the Cache is just too important of a feature to only belong to ASP.NET.

Scott Stanfield said:

The biggest problem you'll run into using the cache outside of a web app is simply the namespace: System.Web. People freak out in code reviews. We got a lot of trash talk from the J2EE world on PetShop because of this.

Chris Kinsman said he seemed to remember some trouble with the Cache not sticking around in memory when used outside of ASP.NET, but that hasn't been substantiated. I'm going to dig more.

Adding System.Web to your non-web project is a good way to get folks to panic. Another is adding a reference to Microsoft.VisualBasic in a C# application. Both are reasonable and darned useful things to do, though.

Wednesday, November 23, 2005 10:50:37 AM (Pacific Standard Time, UTC-08:00)

Where I used to work, we commonly used the System.Web namespace for MailMessages in non-web applications. I've never tried it for using the cache, but I seem to remember someone in a google group using HttpCookie in a WinForm app not that long ago.

I've never used the VisualBasic namespace, what's in there that's useful? Removal of short-circuiting? :P

Marty Thompson

Wednesday, November 23, 2005 11:23:09 AM (Pacific Standard Time, UTC-08:00)

Why not use the Enterprise Library Caching Block from MS Patterns & Practices?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/caching1.asp

Bryan Batchelder

Wednesday, November 23, 2005 11:26:28 AM (Pacific Standard Time, UTC-08:00)

As long as you use it as a cache with proper fallback on regular data calculation/retrieval, it works great in non-web apps or even libraries that could be used in either scenario. The big pitfall is that the cache will gladly let go of data before it has actually "expired" in scenarios like low memory. I suppose that advice goes for using it ASP.net as well. I've just seen people use it like a big global Hashtable in an app, and then it breaks under stess because things are going away and they think something is wrong with it.

Mark Miller

Wednesday, November 23, 2005 11:26:55 AM (Pacific Standard Time, UTC-08:00)

In my opinion that block has way too many moving parts. Using the ASP.NET Cache is fairly lightweight, and includes the very useful cache dependancies stuff.

Scott

Wednesday, November 23, 2005 12:10:08 PM (Pacific Standard Time, UTC-08:00)

public sealed class CacheProvider
{
private CacheProvider(){};

public static Instance
{
get
{
return (HttpContext.Current == null) ? HttpRuntime.Cache : HttpContext.Current.Cache;
}
}
}

or the 2.0 version

return (HttpContext.Current ?? HttpRutime.Cache);

karl

Wednesday, November 23, 2005 12:20:20 PM (Pacific Standard Time, UTC-08:00)

I like to pull in the J# DLLs, too. Just to REALLY freak people out.

Jeff Atwood

Wednesday, November 23, 2005 1:57:11 PM (Pacific Standard Time, UTC-08:00)

Still wonder why the FX team hasn't just moved caching into another (non web) namespace. It pwns for web stuff, but there's no reason you wouldn't want caching in other types of solutions. (And who wants all the bloat of the enterprise libs, etc.)

Honestly, just a simple static object that supports sliding expirations? Seems that that SQL Server 2005 folks would have been clamoring to get SQL Server Cache invalidation working for winforms/WPF applications too.

Michael K. Campbell

Thursday, November 24, 2005 1:35:17 AM (Pacific Standard Time, UTC-08:00)

karl...if you look (reflector) at HttpContext.Current.Cache all it does is return HttpRuntime.Cache.

Scott Hanselman

Thursday, November 24, 2005 4:55:43 AM (Pacific Standard Time, UTC-08:00)

Scott:
So always use HttpRuntime.Cache istead of HttpContext.Current.Cache ;) thanks

karl

karl

Thursday, November 24, 2005 9:30:32 AM (Pacific Standard Time, UTC-08:00)

ObjectDataSource, anyone?

The problem with this one, as I recall, is mostly in setup.

It'd be nice to see BuildProviders pulled out, as well.

Re Cache vs EntLib: Cache has one singular advantage -- it's already there. As much as I pimped EntLib a year ago, it's a download-modify-and-compile project. With all do respect to the hard work that went into it: if I wanted that, I could use Java. I prefer my batteries included.

Keith J. Farmer

Thursday, November 24, 2005 2:28:21 PM (Pacific Standard Time, UTC-08:00)

EntLib Caching block is actually pretty easy to use. I too was concerned that it was a bit hefty/intertwined. If you spend a little time writing your first trival app with it, it planes out fast. It has the same types of dependencies and it allows you to do have a variety of stores (you can have two levels of cache with one backed with memory, one backed with db). It's grown on me for non-ASP.NET ctxs.

Grant

Monday, November 28, 2005 9:44:55 AM (Pacific Standard Time, UTC-08:00)

Most of the conversation has been around enterprise components and the use of ASP.NET cache. Can anyone think of a good reason why the use of the ASP.NET cache on the client side of a rich client app wouldn't work? For these types of applications, preventing a round-trip all together would be the ideal situation. Granted that with rich-client it's easier maintain state but why "roll your own" cache when there is a robust library to do just that. Thoughts?