SPCache vs. HttpRuntime.Cache

I have a SharePoint 2010 Farm and want to use 开发者_高级运维object caching for my own custom objects.

Since it's an ASP.net Application at it's core, I could use HttpRuntime.Cache. On the other hand, SharePoint 2010 offers it's own SPCache.

Why would I choose SPCache over the HttpRuntime.Cache one?

FYI, I went with SPCache at the end. It is indeed a very unusual SharePoint class: Well documented, simple and straight-forward to use, painless to manage.

It does offer the one thing HttpRuntime.Cache does not do: Allowing me to create my own subcaches and invalidating this without wiping the entire HttpCache.

I could achieve the same using a Dictionary inside the HttpCache, but locking around that has some potential issues. I reflected on the SPCache and found a solid, thread safe implementation, so that's what I went with.

As a caveat: SPCache seems to be SharePoint Server only, not for Foundation.

This question is intriguing.

• Google returns no results for implementing SPCache
• A search through unobfusticated code; reveals only two internal classes (DataCache and DBCache) in the User Profile system that use SPCache.

It sounds like you should not use SPCache (but usually the msdn page would say "not intended to be used by user code".)

What kind of custom object are we talking about?

In general you should use HttpRuntime.Cache for custom development (if you develop for old SharePoint web parts you have a way of caching inside the web part). Even though you mention SharePoint at the root is an ASP.NET application, you should prefer HttpRuntime.Cache over HttpContext.Current.Cache. This will make it more portable for unit testing or console apps since you are not dependent of context or System.Web namespace.

This may be obvious, but remember to secure thread safety (eg locking) and also remember that not all SharePoint objects can be serialized.