Nello scorso script (https://www.aspitalia.com/script/1396/Eseguire-Task-Temporizzati-Tramite-Hosted-Service-ASP.NET-Core.aspx) abbiamo visto come realizzare un hosted service in ASP.NET Core per l'esecuzione di task temporizzati.
Un oggetto di questo tipo, senza la possibilità di iniettare servizi tramite dependency injection, è ovviamente parecchio limitato. Per rimuovere questo limite, potremmo essere tentati di accettare questi servizi direttamente nel costruttore, un po' come abbiamo fatto nello script originale con l'interfaccia ILogger:
public MyTimedService(ILogger<MyTimedService> logger, IAccountService accountService, IOrdersService ordersService) { _logger = logger ?? throw new ArgumentNullException("logger"); _accountService = accountService ?? throw new ArgumentNullException("accountService"); _ordersService = ordersService ?? throw new ArgumentNullException("ordersService"); }
Questa soluzione sembra funzionare perfettamente, eppure nasconde un subdolo problema: il rilascio delle risorse.
Cosa succederebbe se, per esempio, IOrdersService utilizzasse internamente un DbContext di Entity Framework? Fintanto che lo utilizziamo in un controller, e quindi nel contesto di una richiesta, il rilascio delle risorse avverrà automaticamente al termine della richiesta stessa. Ma MyTimedService, invece, resterà attivo per l'intero ciclo di vita dell'applicazione, quindi il DbContext non verrebbe mai distrutto, con i problemi di scalabilità che possiamo facilmente immaginare.
L'approccio più corretto quindi è quello di creare un dependency injection scope per la sola durata dell'esecuzione del timer, e per farlo abbiamo bisogno di iniettare l'intero IServiceProvider:
private IServiceProvider _services; public MyTimedService(IServiceProvider services) { // non possiamo usare la constructor injection _services = services ?? throw new ArgumentNullException("services"); }
A questo punto, all'interno del timer, possiamo creare uno scope e, a sua volta, sfruttare quest'ultimo per costruire i servizi di cui abbiamo bisogno:
public Task StartAsync(CancellationToken cancellationToken) { _timer = new Timer( async state => { using (var scope = _services.CreateScope()) { var accountService = scope.ServiceProvider.GetRequiredService<IAccountService>(); var ordersService = scope.ServiceProvider.GetRequiredService<IOrdersService>(); // ... altro codice qui ... } }, state: null, dueTime: TimeSpan.FromMinutes(1), // questo è il delay per la prima esecuzione period: TimeSpan.FromMinutes(1) ); // ogni minuto return Task.CompletedTask; }
In questo modo, la presenza dello scope all'interno del blocco using garantisce che le risorse così create verranno distrutte con la Dispose dello scope stesso, e quindi al termine di ogni iterazione.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
-
Visualizzare le change sul plan di Terraform tramite le GitHub Actions
-
Ottenere il contenuto di una cartella FTP con la libreria FluentFTP
-
Evitare la script injection nelle GitHub Actions
-
Eseguire le GitHub Actions offline
-
Eseguire query manipolando liste di tipi semplici con Entity Framework Core
-
Personalizzare l'errore del rate limiting middleware in ASP.NET Core
-
Utilizzare le collection expression in C#
-
Creare un'applicazione React e configurare Tailwind CSS
-
Usare il versioning con i controller di ASP.NET Core Web API
-
Creazione di plugin per Tailwind CSS: espandere le Funzionalità del Framework
-
Specificare il versioning nel path degli URL in ASP.NET Web API
-
Migrare una service connection a workload identity federation in Azure DevOps
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