In molti script presenti su questo sito, abbiamo visto che per eseguire operazioni prima e dopo il salvataggio dei dati (ad esempio per scopi di logging) dobbiamo eseguire l'override del metodo SaveChanges ed eseguire codice prima e dopo la chiamata al metodo base.
A partire dalla versione 5 di Entity Framework Core, possiamo evitare di alterare la classe che eredita da DbContext e ricorrere agli eventi che internamente il Savechanges metodo solleva. Gli eventi sono:
- SavingChanges: sollevato all'inizio del metodo SaveChanges quindi prima che le entity vengano persistite;
- SavedChanges: sollevato alla fine del metodo SaveChanges quindi dopo che le entity sono state salvate;
- SaveChangesFailed: sollevato in caso la persistenza vada in errore.
Il metodo che gestisce uno di questi eventi accetta in input il sender (che rappresenta il contesto) e un oggetto il cui tipo che cambia a seconda dell'evento:
- SavingChangesEventArgs: in input al metodo che gestisce l'evento SavingChanges. Non offre informazioni aggiuntive;
- SavedChangesEventArgs: in input al metodo che gestisce l'evento SavedChanges. Contiene una proprietà che specifica quanti record sono stati scritti;
- SaveChangesFailedEventArgs: in input al metodo che gestisce l'evento SaveChangesFailed. Contiene una proprietà che specifica l'eccezione sollevata in fase di persistenza.
Queste classi ereditano da una classe base che contiene solo la proprietà AcceptAllChangesOnSuccess.
var context = new MyContext(); context.SavingChanges += (sender, args) => Console.Write("Saving changes"); context.SavedChanges += (sender, args) => Console.Write($"{args.EntitiesSavedCount} Changes saved"); context.SaveChangesFailed += (sender, args) => Console.Write($"SaveChanges failed with exception {args.Exception.Message}");
Eseguire l'override di SaveChanges è indubbiamente più comodo rispetto al sottoscriversi agli eventi. Tuttavia non sempre abbiamo a disposizione la possibilità di modificare il codice della clase di contesto. In questi scenari gli eventi ci consentono di poter applicare comunque la nostra logica.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Disabilitare automaticamente un workflow di GitHub (parte 2)
Gestire domini wildcard in Azure Container Apps
Hosting di componenti WebAssembly in un'applicazione Blazor static
Load test di ASP.NET Core con k6
Implementare il throttling in ASP.NET Core
Miglioramenti agli screen reader e al contrasto in Angular
Estrarre dati randomici da una lista di oggetti in C#
Sfruttare MQTT in cloud e in edge con Azure Event Grid
Eseguire query verso tipi non mappati in Entity Framework Core
Usare lo spread operator con i collection initializer in C#
Evitare la command injection in un workflow di GitHub
Eseguire le GitHub Actions offline
I più letti di oggi
- Tutorial Windows Communication Foundation
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Gestire la cancellazione di una richiesta in streaming da Blazor
- Repository con code-first di Entity Framework
- Blazor: Security
- Utilizzare WebAssembly con .NET, ovunque
- Protobuf: un serializzatore alternativo per WCF