Often drawn to the latest new "thing" but generally try to avoid chasing too many silver bullets.
ASP.NET/React developer by day, blogger and ebook/course builder by night.
This essentially gives you a transaction per web request, so you can be confident the operation either worked or it didn't (and you won't get into a "half n half" state where some things are persisted to the database but others aren't).
By default ASP.NET Core will commit everything in one transaction when you call SaveChanges, so every modified entity will persisted in one go :-)
Does this work because the DB context is a scoped DI service?
Assuming you had, let's say, multiple services that individually made changes via the DB context - all those changes would be saved in bulk at once?
Sounds like that would be a potential performance benefit in generic scenarios too eh?
Very interesting approach 😉
Hi James, yep you've got it.
This essentially gives you a transaction per web request, so you can be confident the operation either worked or it didn't (and you won't get into a "half n half" state where some things are persisted to the database but others aren't).
By default ASP.NET Core will commit everything in one transaction when you call SaveChanges, so every modified entity will persisted in one go :-)
Nice - did not know that! Thanks for the extra details about the transaction.
This tactic has lots of other interesting benefits 👌