24 November 2003

Caching from an Assembly

Hello Friends, it has been too long since the last blog post.  Whidbey is out, its now post PDC and it you have a MSDN Universal subscription, i highly reccomend acquiring yourself some whidbey bits.  I think Whidbey represents some awesome new functionality for ASP.NET and .NET in general.  I'm really excited about a lot of things, Master Pages, Providers, Caching (with new db table dependencies).  Caching is one thing i'd like to discuss a bit, I'm currently working on a 3+ tier application.  It will have a system or kernel type assembly where all the base functionality for the system resides (basically wrapper classes around data access, encryption and caching), an applications assembly that contains all of the business logic for the applications (Employee Time & Expense tracking etc..) and a web front end using asp.net.  I want to leave myself open though in the future, say a big potential client wants to buy the app but really doesn't like web front ends, he wants a client server app.  Well to support this I really shouldn't include any ASP.NET specific functionality in the assemblies (System & Applications).  That however leaves me with a problem.  Architecturally speaking, the best place to do the caching is in those assemblies.  Specifically the Applications one.  Its going to be closest do the data and will have the best shot of reuse.  However to keep with the idea that the application assemblies should not be web specific this presents somewhat of an issue. 

What I'd like to do is make a kernel level (ie goes into my App's system assembly) provider for caching.  Basically this would be a class say CacheManager or CacheEngine that would then implement a custom interface that I've created.  It would also upon creation look into the configuration to find out what type of cache its supposed to be, then load up that specific type (the specific type would be something like the Caching Application Block, or the ASP.NET Cache) as a member.  The specific type would handle all of the caching however it normally would.  This allows me to get all of the advantages of caching while allowing me to use asp.net's built in cache.  I don't have to roll my own :) .  I'm sure this is not a new idea, I'm borrowing the provider idea from Whidbey.  Ok Here's the question.  What is the most performant way of getting at the ASP.NET cache from inside of an assembly?  I think the easiest is to use the HttpContext.Current.Cache but its certainly not the only way.  I thought I'd heard that it was not the most performant way of doing it, and that there were better more performant ways.  Anyone know for sure?  Also, it would be really cool if there was a database independent way of doing table dependent caching. 

I'm going to watch the Giants get crushed tonight on monday night football.  I'm a die hard giants fan with no explaination (beyond the coach who has suddenly decided to become worthless) as to why they're losing.  I admit though, they're quite adept at losing.  I seriously think they'd be 9 - 1 this year had they not beaten themselves 5 times, (i think philly legitimately beat them last weekend).  But on a more positive note, Michigan beat OSU decisively on saturday.  That game was a blast to watch.  Ok I promise to start blogging more.  And about more interesting things.

Comments

# Scott Sargent said:

Absolutely, but as far as I could see the Caching Application Block implemented its own data store, in Memory / A Memory Mapped File / SQL Database. That's very cool and powerful, but if at all possible I'd like to make use of the asp.net caching system. By virtue of using Cache Providers and developing a system that does, I could easily switch if the time came to it. Ie the public class would be something like CacheProvider which would make use of the functionality of ICacheProvider which would be implemented by wrapper classes to the various Caching Systems. ASPNetCacheProvider, CacheAppBlockProvider etc..

Monday, November 24, 2003 1:44 PM
# Rob Howard said:

Yes, do use HttpContext.Current. However, once you have a reference to context try and hold on to it. Constantly referencing the static Current property has some associated cost.

For example, if you have a constructor in the class and you know that you'll be accessing cache everywhere it's best to set a member variable 'cache' to HttpContext.Current.Cache and not use HttpContext.Current.Cache in each method. Make sense?

Monday, November 24, 2003 2:13 PM
# Scott Sargent said:

Definitely, I could make my CacheProvider object a member of the base class (the CacheProvider would in turn have the HttpContext.Current.Cache as a member of its own). That way I ensure that there's one instance of the Cache per class object. Perhaps i could do even better than that if I used a singleton of some sort. That might get me down to one instance per user. Figuring for each instance there'd be a call to HttpContext.Current that would dramatically cut down the cumulative cost of accessing the Current property. The singleton is something to look into in the future, and not really huge importance as it can be added painlessly later.

Monday, November 24, 2003 2:43 PM