Is UnitOfWork equals Transaction? Or it is more than that?
The internet is full of information about UnitOfWork pattern; even SO is not an exception.
I still do not understand something about it. In my understanding UnitOfWork = Transaction in DB. Thats all; nothing more, nothing less.
Is this correct?
My confusion is due to how it is implemented in different ORMs. NHibernate uses ISession for more than just a Transaction. Dapper leaves everything to you.
My question here is about design pattern only without considering any ORM or technology.
If it is more than just Transaction, please explain how.
Edit 1
Reference to this link as suggested in answer by @David Osborne.
A Unit of Work keeps track of everything you do during a business transaction that can affect the database. When you're done, it figures out everything that needs to be done to alter the database as a result of your work.
So this means UnitOfWork is DBTransaction and More.
Following are it's additional responsibilities: -
Maintain state of what you have changed, inserted, deleted in this session of work.
Based on this state, modify the database when work is done.
Although not clearly mentioned in quote above, but it also may control batching of queries.
Is my understanding correct now?
A UnitOfWork is a business transaction. Not necessarily a technical transaction (db transaction) but often tied to technical transactions.
In the enterprise application patterns it is defined as
Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.
It does not define how changes are written nor the storage type.
An applcation might write changes to a
- database using SQL
- file system using streams
- persistence service using http requests
- distributed cache or even in-memory storage using method invocations
A UnitOfWork (business transaction) collects changes to business objects and ensures that other business transactions will only see valid business objects.
E.g. When your application executes a use case it modifies business objects. If two business transactions (usually use cases) are executed in parallel your application must take care about the changes that each business transaction performs and the time when other business transactions will see them.
Technically this is often done using a db transaction. Thus a unit of work is usually a db transaction.
Applications that use ORM-frameworks to handle persistence usually have a one-to-one relationship between the unit of word and the db transaction. So the difference between a unit of work and a db transaction is usually not relevant for developers.
It originates, AFAIK, from the need for ORM tools to track the [persistence] state of objects during a logical/business transaction.
How a unit of work manages this, and its relationship with the underlying storage technology and the objects stored, is an implementation detail.
A database transaction with a number of SQL statements in between, is arguably also a unit of work. However, the key difference, I suppose, is that the unit of work, as defined in the pattern, has abstracted that level of detail to an object level.