Transaction commit pattern about anemicdomainmodel

[vkhorikov]

The controller won't return until all dependencies registered as per web request are disposed of. So, if there's a failure, the client will get a 500. It might be useful to commit early in some cases (e.g. to know if a DB uniqueness key is violated) and so you might want to introduce something like Flush on UnitOfWork. But generally, flushing all changes at the end of the web request is the essence of the Unit of Work pattern, it simplifies the code and increases performance (due to fewer db roundtrips).

[thomasdc]

The controller won't return until all dependencies registered as per web request are disposed of. So, if there's a failure, the client will get a 500.

You are not calling UnitOfWork.Dispose() explicitly in BaseController.Ok(). This means that it will be called when the UnitOfWork object is garbage collected. A potential exception can't bubble up back to the controller in that case. I was able to reproduce this exact behavior.

[vkhorikov]

Wow you are right! I assumed an exception in a scoped dependency will bubble up but apparently they don't. It's not garbage collector, though. It's ASP.NET's built-in DI container that manages scoped dependencies and disposes of them after each web request.

I've pushed an update to UnitOfWork. Could you check on your side that it's working as expected now?

[thomasdc]

Yep, that works fine. Thanks!