On Sitefinity Custom Widget Caching

By February 22, 2017.NET, ASP.NET, C#, MVC, Sitefinity

Sitefinity is Caching too Hard!

If you’ve done software development for any length of time, you’ve likely run into a caching issue. Caching is difficult to get right, but it is so beneficial that we work with it in nearly everything we do. In the case of Sitefinity, it performs caching all over the place. As a result, many aspects of the Sitefinity experience are greatly improved. If you disabled caching for a Sitefinity site altogether, the site would slow down immensely. Sitefinity, by its nature of being a Content Management System, stores the bulk of its content in the site’s backing data store (usually a database), so it would get very chatty if it couldn’t cache. However, like with all caching, we have the issue of cache invalidation to tackle. For built-in content widgets, this is already taken care of. But what if you have a custom content widget? You’ll quickly discover that a Sitefinity page, after rendered the first time, will not re-render even if said content is updated in the backend in some form. In this post I’ll show how you can enable automatic cache busting, so that custom widget caching is implemented correctly and your pages will always update when your content does.

Example: Dynamic Content Widget Implementing Custom Widget Caching

Here we have a controller working with a dynamic content item. This kind of controller implementation for custom widget caching can apply to any dynamic content type. The only thing that has to change is the type that you pass to the caching method. Let’s have a look and break it down.

The first thing you should note is that you have to make your controller implement the “IHasCacheDependency” interface and implement the “GetCacheDependencyObjects” method. This is the cornerstone of custom widget caching. Inside you see we are returning a single CacheDependencyKey, and tying it to our custom content type.

“SubscribeToCacheDependency” is the method you use to wire in any of your MVC actions to the caching mechanism. Note how in our Index action the first thing we do is call it.

That’s all there is to it! Now our widget will tell any pages it is on to re-run and get fresh data, instead of being stuck with stale cached date. Custom widget caching is really that simple!

Example: News Content Widget Implementing Custom Widget Caching

This will look much like the above example, but I wanted to demonstrate how to set up caching for a built-in Sitefinity content type.

You see here that with the exception of GetCacheDependencyObjects creating a key whose type is “typeof(NewsItem)”, everything else plays out exactly the same. For built-in Sitefinity content types, you pass the type of the Model item (in this case, NewsItem) in order to configure it properly.

Refactoring Custom Widget Caching Widgets to Share Code

Since the two above are so similar, we definitely would want to refactor it. What we can do is create an abstract base class to make custom widget caching easy to implement going forward.

Our base class now handles the boilerplate code, as well as deciding the correct kind of CacheDependencyKey to create and return. Look how easy it is to slap on to any custom widget! We inherit from the abstract class, implement the CachedObjectType, and call SubscribeToCacheDependency in any action we wish to cache. Custom Widget Caching is now incredibly simple!

If you have multiple types you wish to enable, then this particular refactor won’t work. It could easily be adjusted to accept a list of Types to cache, however. GetCacheDependencyObjects would simply have to be adjusted to return the list of types, instead of the list of a single type.

With this new tool in your arsenal, you can now continue to use the power of caching in your Sitefinity site, while making sure custom widget caching is in place to bust caches and prevent your site from serving stale content.

The following two tabs change content below.