Custom Dependency Injection Resolver for ASP.NET Core 2.x Middleware?

user_1142433 0
Viewed 1276

Given an ASP.NET Core 2.x application, let's say I'm using two distributed cache mechanisms:

services.AddDistributedSqlServerCache()
services.AddDistributedRedisCache()

As I understand it, since Redis was registered the last, anytime an instance of IDistributedCache is requested, it resolve to the RedisCache implementation.

In my project, I am also using the Distributed-Cache tag helper, which I want to resolve to RedisCache (no problem, works with the above setup).

I am also, however, using Session middleware, which also asks for an IDistributedCache implementation.

I need the Session middleware to resolve to the SQL distributed cache and the Distributed-Cache tag helper as well as any other request for IDistributedCache cache to resolve to the RedisCache.

If I understand this article correctly, you can specify which implementation the service locator resolves to for generic calls to services.AddSingleton, but that doesn't seem to translate middleware registration helper functions like AddSession().

Any ideas how to solve this?

asp.net-core-middleware asp.net-core c#
1 Answers

Both AddDistributedSqlServerCache() and AddDistributedRedisCache() register a singleton for IDistributedCache: SqlServerCache and RedisCache respectively. Since dependent components just depend on IDistributedCache, they will all get the same distributed cache implementation (depending on what was registered last).

This is generally by design because implementation, e.g. the session middleware, should not care about what the actual registered implementation of IDistributedCache is. It just depends on there being some and uses that. And equally, other services will also just use the one distributed cache dependency.

Usually, there wouldn’t really be a way around this. What you could eventually do is create some adapter that implements IDistributedCache itself and then delegates to either the SQL Server cache or the Redis cache depending on the passed arguments.

In your case, there is a simpler way though. Since ASP.NET Core is built to be very extensible, and most components can be simply swapped by other implementations, we can utilize this here to make the session middleware just use a specialized distributed cache while everything else falls back to the default cache.

For this, we just implement ISessionStore and register that, which is basically what AddSession() also does. In the custom session store implementation, instead of depending on IDistributedCache we will just depend on SqlServerCache directly. So that way, we do not fall back to the default IDistributedCache (whatever that would be), but force the system to use a SqlServerCache.

public class SqlServerCacheSessionStore : ISessionStore
{
    private readonly IDistributedCache _cache;
    private readonly ILoggerFactory _loggerFactory;

    public SqlServerCacheSessionStore(SqlServerCache cache, ILoggerFactory loggerFactory)
    {
        _cache = cache ?? throw new ArgumentNullException(nameof(cache));
        _loggerFactory = loggerFactory ?? throw new ArgumentNullException(nameof(loggerFactory));
    }

    public ISession Create(string sessionKey, TimeSpan idleTimeout, TimeSpan ioTimeout, Func<bool> tryEstablishSession, bool isNewSessionKey)
    {
        if (string.IsNullOrEmpty(sessionKey))
            throw new ArgumentNullException(nameof(sessionKey));
        if (tryEstablishSession == null)
            throw new ArgumentNullException(nameof(tryEstablishSession));

        return new DistributedSession(_cache, sessionKey, idleTimeout, ioTimeout, tryEstablishSession, _loggerFactory, isNewSessionKey);
    }
}

This is literally the same implementation as DistributedSessionStore, which is the default ISessionStore implementation, except that we depend on SqlServerCache instead of IDistributedCache.

Now, we just need to wire everything up in the Configure method:

// we keep the Redis cache as the default
services.AddDistributedRedisCache();

// no call to `AddSqlServerCache` as we don’t want to overwrite the `IDistributedCache`
// registration; instead, register (and configure) the SqlServerCache directly
services.AddSingleton<SqlServerCache>();
services.Configure<SqlServerCacheOptions>(options =>
{
    // here goes the configuration that would normally be done in the
    // configure action passed to `AddSqlServerCache`
    options.ConnectionString = Configuration.GetConnectionString("DistributedCache");
});

// add session, but overwrite the `ISessionStore` afterwards
services.AddSession();
services.AddTransient<ISessionStore, SqlServerCacheSessionStore>();

And that should be all. So when the session middleware now resolves the ISessionStore it will get the SqlServerCacheSessionStore which directly depends on the SqlServerCache instead of the general IDistributedCache which will be the Redis cache.

user_2160740
Related