What is the Unit of Work pattern?
Quick Answer
Unit of Work tracks every change made during a business operation and commits them together in a single transaction (or discards them all). It defines the transaction boundary. In EF Core, DbContext is the Unit of Work — you make changes across several repositories and call SaveChanges() once.
Unit of Work is about grouping all the changes in one business operation into a single transaction — order created, stock reduced, audit written, all committed together or not at all. It owns the transaction boundary. In EF Core the DbContext already does this: the change tracker collects everything and SaveChanges commits it in one transaction. So adding an explicit IUnitOfWork on top of EF is usually just a wrapper around SaveChangesAsync. It earns its place when you're coordinating more than one data store.
The point is atomicity across multiple aggregates: creating an order, decrementing stock and writing an audit row should all succeed or all fail. Without a unit of work you'd have three separate saves and a half-finished state on failure.
EF Core gives you this for free because the context accumulates changes in its change tracker and SaveChanges() wraps them in one transaction. An explicit IUnitOfWork interface on top of EF is usually redundant — its only method would be SaveChangesAsync(). It's more useful when you genuinely have multiple data sources to coordinate, or want to hide the context from the application layer for architectural reasons.