...
- a user action involving one or more domain objects
- these domain objects are referencing each other
- the involved domain objects are committed to the
database together (if the user desires it and clicks
Save instead of Cancel)
The unit of work is the central concept behind re-motion
client transactions. It is practical to understand a
client transaction and its sub-transactions as spanning
a unit of work.
Details
A unit of work is started by the user, typically by opening
some form in a session. No matter whether the user will
eventually modify the data or opens the form just for browsing,
SOME client transaction is required to display a domain object's
data in the form. In re-store, it is the client transaction
that has the container for domain object data in its belly,
so without a client transaction, this data can't even be loaded
from the database, let alone displayed. In other words: without
client transactions, domain object instances are like fish out
of water and have no life. Since re-store loads only objects that
the user (or some other part of the program) needs, more and
more domain objects get loaded into client transactions if the
user works her way through object relations and opens more forms.
The unit of work ends when the form that started the unit of
work has been closed – be that for Save-ing modifications
(Commit()) or clicking the Cancel button (Discard ()). All the
involved objects - loaded when the user opened forms for
displaying/editing them - are part of the unit of work and loaded
into a client transaction. Again: client transactions are the
ony only place into which domain object instances can be loaded.
Thus there is an intimate connection between units of work, domain
objects and client transactions.
Let's turn our attention to an illustrated example of a unit of
work. This example builds on a web user interface, which in
re-motion is typically covered by re-call. Client transactions
are designed to work well with re-call, but not exclusively.
Let's say executive assistant Miss Quackfaster works for a large
corporation and uses a re-motion web application for managing personnel
and their resources. Now she wants to update the number of the fax in
the car of the company's CEO. We assume that Miss Quackfaster
has no other domain objects loaded at this time and no pending
client transactions. The unit of work begins when she opens
the domain object representing the CEO. This object has a relation to the
CEO's car, so Miss Quackfaster follows a link to open the form for
editing the car object. This Car domain object in turn has a reference
property to the domain object representing the car's fax. What
Miss Quackfaster wants is the Fax object's Number property. Here
is an illustration for the chain of events. The boxes are cartoon
versions of domain object instances with their properties. The
colorful rectangles next to each are browser windows for displaying
and editing that domain object:
...
As soon as Miss Quackfaster has edited the fax' phone-number,
she clicks on Save. This closes the EditFax form, and the EditCar
form becomes visible in Miss Quackfaster's browser. She clicks
Save in this form, too, and ends up with the EditBoss form. With
a click on the EditBoss form's Save button, the unit of work ends.
Whatever has been changed during the unit of work has made it into
the database, because Miss Quackfaster clicked on all those Save
buttons.