Uno dei concetti rimanenti per chiudere il cerchio sulle peculiarità dell'output cache di ASP.NET Core 7 è la rimozione programmatica di elementi in cache al verificarsi di un determinato evento, per esempio quando modifichiamo i dati sul database.
Immaginiamo per esempio di avere una base policy che memorizzi le risposte in cache per un'ora:
builder.Services.AddOutputCache(config => { config.AddBasePolicy(policy => { policy.Expire(TimeSpan.FromMinutes(60)); }); });
L'idea a questo punto, è quella di assegnare ai vari endpoint uno o più tag, così che possiamo poi usarli per individuare le corrispondenti cache entry:
app.MapGet("/cachedemo", () => { return $"Time is {DateTime.Now.ToLongTimeString()} and this is cached"; }).CacheOutput(policy => { policy.Tag("all"); policy.Tag("cachedemo"); }); app.MapGet("/anotherEndpoint", () => { return $"Time is {DateTime.Now.ToLongTimeString()} and this is cached"; }).CacheOutput(policy => { policy.Tag("all"); policy.Tag("another"); });
Nell'esempio in alto abbiamo definito due endpoint Minimal API, ai quali abbiamo assegnato un paio di tag, cachedemo e another. Nel nostro caso, abbiamo sfruttato il policy builder del metodo CacheOutput, ma alternativamente possiamo anche creare due policy distinte (https://www.aspitalia.com/script/1442/Definire-Durata-Output-Cache-ASP.NET-Core.aspx) e configurare i tag all'interno di esse, invece che nei singoli endpoint.
Ora che queste risorse sono memorizzate con i corrispondenti tag, abbiamo la possibilità di rimuoverle programmaticamente, tramite il metodo EvictByTagAsync di IOutputCacheStore. Un modo per fare facilmente qualche prova è quello di esporlo tramite un endpoint:
app.MapPost("/evict/{tag}", async (string tag, IOutputCacheStore cache) => { await cache.EvictByTagAsync(tag, CancellationToken.None); });
Come possiamo verificare, a seconda del parametro utilizzato (cachedemo, another o all) rimuoveremo dalla cache rispettivamente il primo endpoint, il secondo, o entrambi.
Una limitazione di questo approccio è che i nomi dei tag sono statici, ossia non abbiamo modo di referenziare parametri della richiesta. Per risolvere questo problema dovremo costruire una custom cache policy, che sarà oggetto di un prossimo script.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Popolare una classe a partire dal testo, con Semantic Kernel e ASP.NET Core Web API
Utilizzare WhenEach per processare i risultati di una lista di task
Sfruttare gli embedding e la ricerca vettoriale con Azure SQL Database
Gestire eccezioni nei plugin di Semantic Kernel in ASP.NET Core Web API
Selettore CSS :has() e i suoi casi d'uso avanzati
Change tracking e composition in Entity Framework
Persistere la ChatHistory di Semantic Kernel in ASP.NET Core Web API per GPT
Path addizionali per gli asset in ASP.NET Core MVC
Generare una User Delegation SAS in .NET per Azure Blob Storage
Configurare lo startup di applicazioni server e client con .NET Aspire
Ottimizzare le pull con Artifact Cache di Azure Container Registry
Effettuare il refresh dei dati di una QuickGrid di Blazor