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 its 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?
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.