unit of work

A unit of work is roughly understood here as:

• 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 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.