Should we use a generic cache manager in our .NET boilerplate?

JanL@kentico.com[email protected] Czech RepublicMember, Administrator, Kentico Staff admin

Hello .NET developers!

I'd like to ask you about what your preference regarding caching in our .NET boilerplate project is.

There are several cache manager libraries out in the wild. One of the nice ones is https://github.com/MichaCo/CacheManager . It supports various caching technologies (incl. distributed ones) and is designed to store various types of data in the cache (not only Kentico Cloud data).

The question is: Would you welcome such a generic cache manager in our boilerplate?

Pros:

  • support for multiple caching technologies
  • state-of-the-art caching patterns implemented (failover mechanisms, geo-replication, etc.)
  • optimized for performance

Cons:

  • lack of support for cache item dependencies
  • lack of support for type dependencies (eg. if one content item is cached twice as both strongly-typed object and an object of type "dynamic", then both should be invalidated at the same time)

Pros and cons (at the same time):

  • designed for generic usage (not with Kentico Cloud data in mind)

Currently, I'm in the process of adding support for invalidating cache items with webhook calls into the boilerplate. Part of the implementation is a CacheManager class designed primarily for in-memory caching of Kentico Cloud data (with the aim to also support storing of other types of data). While my optimized CacheManager seems to perform better than generic caching solutions, there is still one rule of thumb that is worth considering: "The best code is the one that wasn't written."

What is your opinion on this?

Thanks

Jan

Answers

  • leelee Member ✭✭

    Could you provide an interface instead so that developers could plug in their own cache manager?

    ICacheManagerProvider

    This way, you get a standard interface to call when building the boilerplate and can build your simple in-memory cache to that interface but still leave it open for developer to easily swap it out for other caching libraries.

  • JanL@kentico.com[email protected] Czech RepublicMember, Administrator, Kentico Staff admin

    Hi @lee , yes, that's the ideal scene. However, it will require further investigation as the cache managers differ significantly in the way they handle dependencies (if at all).

    But, as I've been thinking about all the principial underpinnings of caching, I tend to coming to a conclusion that dependencies should be resolved not at the cache entry build time, but at the invalidation time (dynamically). This way we could overcome that hurdle with the diversity of those cache managers eventually.

    Thanks for your point @lee !

Sign In or Register to comment.