Reputation: 180874
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?
Upvotes: 3
Views: 2370
Reputation: 180874
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.
Upvotes: 4
Reputation: 862
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.
Upvotes: 1
Reputation: 6765
This question is intriguing.
It sounds like you should not use SPCache (but usually the msdn page would say "not intended to be used by user code".)
Upvotes: 1