Strongly-Typed Redis Caching in ASP.NET Core (Without the Boilerplate)

If you've added Redis to an ASP.NET Core app, you've probably met IDistributedCache. It does the job, but it only speaks in byte[] and string keys. So every read or write turns into the same little ritual: serialize, null-check, deserialize. Do that in one place and it's fine. Do it in twenty, and you've got a pile of nearly identical caching code that's surprisingly easy to get wrong.

This post keeps Redis as your store but caches typed objects instead of byte arrays, using a small open-source package called CacheManager.Redis. We'll look at the boilerplate problem, write a clean cache-aside method, prefix keys for shared Redis, and figure out when you'd actually want to reach for something else.

The boilerplate problem with IDistributedCache

Here's the usual cache-aside read with the raw IDistributedCache:

public async Task<Weather?> GetForecastAsync(string city, CancellationToken ct)
{
    var key = $"forecast:{city}";

    var bytes = await _cache.GetAsync(key, ct);
    if (bytes is not null)
        return JsonSerializer.Deserialize<Weather>(bytes);

    var forecast = await _api.LoadForecastAsync(city, ct);

    await _cache.SetAsync(
        key,
        JsonSerializer.SerializeToUtf8Bytes(forecast),
        new DistributedCacheEntryOptions { SlidingExpiration = TimeSpan.FromMinutes(10) },
        ct);

    return forecast;
}

None of this is hard. But the serialization, the null handling, and the expiration options all live in your business logic, and they get copy-pasted into every service that touches the cache.

A typed wrapper over the same Redis

CacheManager.Redis is a thin layer over Microsoft.Extensions.Caching.StackExchangeRedis. It doesn't replace Redis or StackExchange.Redis. It just wraps the distributed cache so you work with T instead of byte[], and it handles System.Text.Json for you.

Install it:

dotnet add package CacheManager.Redis

using CacheManager.Redis.Extensions;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRedisCacheManager(
    builder.Configuration.GetConnectionString("Redis"),
    options =>
    {
        options.InstanceName = "myapp:"; // optional key prefix
        options.DefaultCacheOptions = new DistributedCacheEntryOptions
        {
            SlidingExpiration = TimeSpan.FromMinutes(10)
        };
    });

That one call sets up AddStackExchangeRedisCache for you and registers IRedisCacheManager<T> so you can inject it anywhere.

Cache-aside, now strongly typed

Inject IRedisCacheManager<T> and that same read gets a lot shorter:

public sealed class ForecastService
{
    private readonly IRedisCacheManager<Weather> _cache;
    private readonly WeatherApi _api;

    public ForecastService(IRedisCacheManager<Weather> cache, WeatherApi api)
    {
        _cache = cache;
        _api = api;
    }

    public async Task<Weather> GetForecastAsync(string city, CancellationToken ct)
    {
        var key = $"forecast:{city}";

        var cached = await _cache.GetAsync(key, ct);
        if (cached is not null)
            return cached;

        var forecast = await _api.LoadForecastAsync(city, ct);
        await _cache.SetAsync(key, forecast, ct); // uses the default expiration from registration
        return forecast;
    }
}

No serializer calls, no byte[], no casting. GetAsync gives you back a Weather? (null on a miss), and SetAsync stores the object using the JSON settings you set once at startup.

If you'd rather not throw on bad keys, there are best-effort TryGet and TrySet overloads that return false for null or whitespace keys instead of throwing. One thing worth knowing: TryGet is synchronous, so the async read path is GetAsync.

Key prefixing for shared or multi-tenant Redis

A single Redis instance often gets shared across apps or tenants. The InstanceName option prefixes every key this manager writes, so myapp:forecast:london won't collide with some other service's forecast:london:

options.InstanceName = "myapp:";

You set it once, and your call sites stay clean with logical keys like forecast:london.

Consistent serialization across the app

Because the System.Text.Json options live in your registration, every cached type serializes the same way (camelCase, enums as strings, whatever you pick) without each caller passing settings around:

options.SerializerOptions = new JsonSerializerOptions
{
    PropertyNamingPolicy = JsonNamingPolicy.CamelCase,
    Converters = { new JsonStringEnumConverter() }
};

Adding logging or metrics with a decorator

Cross-cutting stuff stays out of your core code. Implement IRedisCacheManager<T>, hand off to an inner instance, and register it with Scrutor:

public sealed class LoggingCacheManager<T> : IRedisCacheManager<T> where T : class
{
    private readonly IRedisCacheManager<T> _inner;
    private readonly ILogger<LoggingCacheManager<T>> _logger;

    public LoggingCacheManager(IRedisCacheManager<T> inner, ILogger<LoggingCacheManager<T>> logger)
    {
        _inner = inner;
        _logger = logger;
    }

    public bool TryGet(string key, out T? response)
    {
        var hit = _inner.TryGet(key, out response);
        _logger.LogDebug("Cache {Result} for {Key}", hit ? "hit" : "miss", key);
        return hit;
    }

    // Delegate the remaining IRedisCacheManager<T> members to _inner.
}

builder.Services.AddRedisCacheManager(connectionString);
builder.Services.Decorate(typeof(IRedisCacheManager<>), typeof(LoggingCacheManager<>));

That's how you add hit/miss metrics or structured logging today, without touching the caching logic itself.

When to use it

A quick gut check, because picking the wrong tool just wastes your afternoon.

Reach for CacheManager.Redis when you want typed, low-ceremony cache-aside over Redis in an ASP.NET Core app, you're already happy with how IDistributedCache behaves, and you'd rather not rebuild a serialization wrapper in every project.

CacheManager.Redis stays small on purpose. A few things on its public roadmap (a one-call GetOrSet, async Try variants, and opt-in instrumentation) are planned but not shipped yet, so think of them as where it's headed rather than what's in the box today.

Give it a try

Distributed caching in ASP.NET Core doesn't have to mean byte arrays and copy-pasted JSON. A typed wrapper like CacheManager.Redis lets you keep Redis and IDistributedCache underneath while your code works with real objects, one serialization setup, and one place to handle expiration and key prefixes.

It targets net8.0 and net10.0. If you want to give it a spin:

📦 NuGet: nuget.org/packages/CacheManager.Redis
⭐ Source and issues: github.com/arefLA/CacheManager.Redis

Hit a rough edge, or want GetOrSet sooner? Open an issue. Feature requests really do shape what gets built next.

Got a caching pattern you keep rewriting? Drop it in the comments. It might just be the next feature.

推荐订阅源

DEV Community