Cache stack builder delegate which provides IServiceProvider

My current scenario is that I have a class which provides my Redis connection, and which I register as a singleton in DI. I share this connection with other services in my project via DI. The new fluent cache stack builder doesn’t provide me a way to resolve my connection provider when building the cache stack.

I also don’t need the context in my cache stacks, but I do need to register multiple cache stacks. So below, I’ve subclassed CacheStack to register within DI.

I’m having to do something like this currently.

services.AddSingleton(sp =>
{
    var redisProvider = sp.GetRequiredService<IRedisConnectionProvider>();

    return new MainCacheStack(
        new ICacheLayer[]
        {
            new MemoryCacheLayer(),
            new RedisCacheLayer(redisProvider.RedisConnection, new RedisCacheLayerOptions(ProtobufCacheSerializer.Instance, redisOptions.Database))
        },
        new ICacheExtension[]
        {
            new AutoCleanupExtension(TimeSpan.FromMinutes(5)),
            new RedisLockExtension(redisProvider.RedisConnection,
                new RedisLockOptions(TimeSpan.FromMinutes(1), "CacheTower:CacheLock", "Lock:{0}", redisOptions.LockDatabase,
                    LockCheckStrategy.WithSpinLock(TimeSpan.FromMilliseconds(100)))),
            new RedisRemoteEvictionExtension(redisProvider.RedisConnection)
        });
});

[ErikPilsits-RJW]

On first look it’s exactly what I need. I guess it’s actually more like IOptionsSnapshot<T>.

One thought though. Your current implementation creates new provider, lookup, and accessor singletons for every type of ICacheStack<TContext>. I don’t think that’s strictly necessary. The provider and lookup could hold object which gets typed in the accessor.

[ErikPilsits-RJW]

I would have been comfortable using ICacheStack<T> with different context types for my different layers if I could have resolved dependencies. In fact I was going to use it in my solution, however I wasn’t able to directly create a CacheStack<T> due to the protection level of ServiceProviderContextActivator. I didn’t feel like duplicating that code locally.

My initial thought for supporting multiple stacks was something akin to IHttpContextFactory where you could register a named stack and retrieve it through a factory class.

The background refreshes are an interesting situation (having re-read it now). Thinking on my usage I believe I’m ok without using the context (project has been running for almost 2 years without it). I don’t refresh directly from any disposables that might be disposed externally, it’s all api based data fetches.