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
Reactive form tipizzati con FormBuilder in Angular
Generare file PDF da Blazor WebAssembly con iText
Cambiare la chiave di partizionamento di Azure Cosmos DB
Utilizzare la libreria Benchmark.NET per misurare le performance
Ottimizzazione dei block template in Angular 17
Specificare il versioning nel path degli URL in ASP.NET Web API
Ottenere il contenuto di una cartella FTP con la libreria FluentFTP
Implementare il throttling in ASP.NET Core
Utilizzare la versione generica di EntityTypeConfiguration in Entity Framework Core
Utilizzare le collection expression in C#
Sfruttare MQTT in cloud e in edge con Azure Event Grid
Personalizzare l'errore del rate limiting middleware in ASP.NET Core
I più letti di oggi
- Utilizzare Docker Compose con Azure App Service
- Utilizzare QuickGrid di Blazor con Entity Framework
- Modernizzare le applicazioni WPF e Windows Forms con Blazor
- ASP 3 per esempi
- annunciato #netstandard 2.1. .NET Core lo supporterà a partire da #netcore3, così come le prossime versione di #xamarin, #mono e #unity.il supporto per #netfx 4.8, invece, non ci sarà. https://aspit.co/bq2
- Steel Style CheckBox per Silverlight 4.0