Is UnitOfWork equals Transaction? Or it is more than that?

Question

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 understan

Answer 1

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.

Answer 2

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.