Possible FusionCacheServiceCollectionExtensions improvement about fusioncache

[adambajguz]

Hi @jodydonetti. Awesome! I think the new manual is great for new lib users to see the recommended approach with DI.

[jodydonetti]

Ah, good points!
It's some time already that I wanted to sit down and take a better look at the DI setup part, for some of the reasons you pointed out and then some.
Give me some time to write them down here, so that we can discuss the best way to proceed 👍

[jodydonetti]

Hi @adambajguz , some time has passed 😅 and now I'm getting back to my backlog.

Rationale

[...] useDistributedCacheIfAvailable allows to skip distributed cache setup during AddFusionCache call, so that it can be setup later using setupCacheAction. Thus, defered setup through setupCacheAction allows to e.g. resolve a IOptions that may store whether to use distributed caching or not. Unfortunately, backplane "auto" setup cannot be disabled through a parameter.

I'd like to explain my thought process here.

Since FusionCache uses any impl of the the standard IDistributedCache interface as a 2nd level, what may happen is that one such impl is already registered in your app for other reasons, and you may not want to use a FusionCache 2nd layer only because you (or another component) have registered that somewhere at startup.

For example ASP.NET itself automatically register one in case it is needed by the cache tag helper, and even more strangely so it automatically registers a MemoryDistributedCache, which is not actually distributed at all: that is the reason btw why I also included an ignoreMemoryDistributedCache param that defaults to true.

The logic here is that the default experience would be something like "if there is an impl of IDistributedCache (except the fake one) use it" .

Backplane

Having said that, the backplane is a different thing altogether.

It requires an impl of a specific IFusionCacheBackplane interface, and there can't possibly be one registered automatically or "by mistake": you have to register that explicitely via AddFusionCacheStackExchangeRedisBackplane so there are no surprises there. If you don't want to use a backplane, don't call the registration method, it will not start automatically. And if you want to do that based on some config or logic, you can just put an if around the backplane registration instead, and nothing else will be affected by that.

Now let's say you want to have the ability to have the backplane added to an existing FusionCache instance later on, at some point based on some logic or event: you simply have to not register it via AddFusionCacheStackExchangeRedisBackplane and, when the time comes, you'll be able to just do this:

_cache.SetupBackplane(new RedisBackplane(...));

and that's all is needed.

So

Now, having said all of this in regard to the specific point about the backplane, I'm still open nonetheless about the more broad concept of having more customization available in the DI registration phase, so I'm thinking about expanding it.

Hope this helps.

If you can I'd like to know your opinions about this.

[jodydonetti]

Hi @adambajguz , I've added a new doc specific about DI here: if you like please let me know what you think.

Thanks!