Unit of Work in ASP.NET Core 

Chances are low but to keep the right to migrate from EF to Dapper for example. You can ask the same question as to why work with repositories if "EF is already a database abstraction".

@@kneeh actually I use repos only a few times, for stuff that are queried the same way all the time. But must of the times I find that using dbContext directly in a query handler makes perfect sense, since queries are generally different for each case

​@@stefan-d.grigorescu And that's perfectly fine, that all depends on the requirements. 1. I was involved in a project that needed fast POC, so we use EF and migrated to Dapper, Abstraction was our savior. 2. I rather see a method name than a chain of LINQ calls from EF, and if I already refactor LINQ to a method, why would abstract it entirely, it will also clean up testing by much (the testing suite doesn't need to know about EF).

@@kneeh For 2. I also like extracting such parts of a bigger method into more focused smaller methods in the same handler class That way, the top level method still reads nice

I recommend Christopher Alexander

​@@RawCoding Hello Anton Are you talking about a specific book or something? Can you please share the name or some URL. Thanks.

unit of work is meant to be a buffer for an operation, so to speak. Transition between the operations is not a concern of unit of work, so the answer is you don't..

its more like hack but you can cast and save manually xD

Another thing is that without "bulk update" and no rollback mechanisms in place the implementation of SaveChangesAsync does not provide atomicity which UnitOfWork pattern should provide, so again in real world you should have rollback mechanism for situation in which saving throws an exception half way through your dirty objects.

good shout!

@@RawCoding It's easy to use Decorate extension for IServiceCollection from Scrutor nuget package, IMHO

@@Kosa39 I would love to see a gist of your solution on that. Would you catch the exception, delete all the inserted objects and throw a new exception? And I'm not following the first comment about solving it with a decorator (sry I'm plowing a lot of videos about this right now, not grasping it yet)

Basically answer to the question: "How to handle exceptions when adding/modyfing multiple records in a atomic manner" is as always: It depends. You need to find out what happens in a given situation, maybe no rollback mechanism in your case would be sufficient enough. Let's say you're saving using unit of work items to the redis cache, half way through your objects redis crashes and exception is raised, now let's think how much damage it will do to the system. Well if it is just the cache, user requesting the data will have to reach out to the source system to get the fresh data, is it painfull ? Sometimes it would but more often not i would say, so you can just idk. log the exception and forget about it. However i would highly reconsider is the pattern used correctly, because we know that this is not atomic, and we cannot guarantee atomicity, so we have not acomplished main principle of this pattern. Now, another scenerio, in your UnitOfWork firing bunch of POST requests in attempt to store some data in some external API, again, halfway through API service dies (maybe because you spammed it so hard, lol), is it painfull ? I would say yes, you only saved half of the data that should be saved in a "all or nothing" manner (atomicity), at this point we already know that UnitOfWork pattern is misused in here, you cannot guarantee atomicity (it would be a different matter if your POST request accepted in the body list of the objects you're about to save, in that case you can guarantee the atomicity). Now we're entering the world of distributed computing etc. but in a nutshell you have three options: 1. Eventually rollback commited data 2. Eventually save everything (eventual consistency) 3. Inform a user in some way that the operation succeded partially, and let him handle that There're numbers of ways to achieve this i.e. SAGA pattern for multi staged distributed transactions, Outbox pattern etc. For your second question about decorator pattern, I would simply use Scrutor nuget which has Decorate extension method and does everything for you. An example can be found here: andrewlock.net/adding-decorated-classes-to-the-asp.net-core-di-container-using-scrutor/#using-scrutor-to-register-decorators-with-the-asp-net-core-di-container

correct, I unregister it because not many people know how to do it so I wanted to show it, and hopefully someone asks a question like you did. If we don't unregister there will be 2 implementations in DI, so you could resolve an IEnumerable which I didn't want.

@@RawCoding Ah ok, fair enough... Threw me for a loop for a moment. Thanks for cutting through the bullshit with your videos!

I've read the definition of UoW at the beginning, let me know if that sounds like one to you. hint: what's considered or what you might have heard might not be correct. imo if you need to use 2 dbcontext's in the same place, you fked up

no youd have to implement that

Scoped means 1 per request. The reason we’re doing cache is because I’m illustrating what implementing a unit of work entails - it’s entity change tracking per scope.

People talk a great deal about "abstracting data store implementation" But their wrapper/interface whatever will still rely on the underlying change tracking done by EF Core, effectively having a leaking abstraction, if you were to replace it with something else you'd have your whole app break. And then there is obviously the "easy to test" camp of people, again due to leaking abstraction your tests are useless in this scenario because they depend on the leaking behaviour. My suggestion is use DbContext directly, you are abstracting the data provider via their Provider implementations.

​@@RawCoding So basically what you're saying is that Clean Architecture or Port and Adapters architecture doesen't make any sens since it's all about seperating business concerns from the implementation details ?

They do make sense, I'm saying DbContext is that separation

@@RawCoding got ya

@@RawCoding repositories are a leaky abstraction in this sense only if you assume that they commit changes. Which they should, if you're being dogmatic about the meaning of repositories. But from a pragmatic point of view, separating the DAL into repositories and unit of work makes testing and development so much easier and faster. As long as you don't assume that a repository is committing changes and assert that SaveChanges is called, the tests are not useless.

Are you watching on a phone?

I'm interested to know, how do you ensure the integration events are flushed after confirming that the database transaction succeeded? Could the system be left in an inconsistent state if flushing the events fails for some reason?

I am planning on coming after the OOP & Architecture community later, need more data :D

Yeah, cause anemic models are waaaay better...

Sounds like blind dogmatic belief

@@RawCoding To some extent, yes. But, which part are you referring to? Caching data temporarily for performance reasons is legitimate, so is translating to DTOs in certain contexts. So while there is generally some dogma involved with people using “UoW/Repository over EF”, you can see why they think it is necessary, right? I am asking you to provide an alternative explanation because I have learned things on your channel.

I’m referring to bolting things on to / around the db context and calling it unit of work.

@@RawCoding I don’t think we disagree, but what you are saying is vague. As a counterpoint, doesn’t it follow logically that extending a library unit of work needs to still support and “hook into” that unit of work? I am trying to nail down the crux of what makes people do this specifically with EF. Your point about the general concept of unit of work is correct, I am not disagreeing there. But instead of trying to understand why people do this with specifically over EF, you demonstrated the general concept of unit of work using a completely unrelated example. While I think that is helpful in its own right, it fails to address why people do the behavior you are addressing. It comes down to more than just not understanding what unit of work is, even though I agree that many don’t. The issue is needing to extend EFs unit of work functionality and/or provide abstraction from Ef. There is some legitimacy to those ideas (not that the conclusions are correct) that I think addressing would clear the air more in addition to the content in this video, which I am saying is good; I’m not disagreeing with it. It just isn’t enough.

It’s hard to explain why, tho let’s start with a list of how people try to extend the dbcontext 1. The main thing I see is they wrap the dbcontext behind interfaces to remove a dependency (which is bs) or to make it more testable (which is also bs) They rely on change tracking behind the interface which the interface doesn’t guarantee, so it’s a bad interface and bad tests which don’t test what actually happens. People can’t see this because they just took someone elses word for it that this is best practice, how can you not when Microsoft blog says this. If you can continue this list I’ll let you know which points are legit and perhaps why people try to bolt this on to the dbcontext

They dont

exactly, DbContext implements unit of work putting stuff around it and calling it unit of work is bullshit "change tracking" and "figuring out what to write to db" are capabilities of unit of work

As soon as you swap out ef core it’s no longer unit of work because no tracking is happening of what should be written back to the database. You have to make sure whatever you are swapping it to has UoF under the hood as well. So no interfaces and wrappers are not unit of work.

@@RawCoding Hmm, valid point. Will try to dive more into this once I have more time. Thanks for the explanation.

No LinqPad on Mac :(

it is what it is

Is there anything this implementation would not cover for a reason you would use the UoW pattern?