The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Isn't a Domain Object it's Own Unit of Work?

I don't understand the usefulness of the Unit of Work pattern. Let's say I have a domain class called Contact. When I do:

Contact record = new Contact();

Internally, the Contact knows that it's a new record because it hasn't been loaded from the database yet. Then I do:

record.FirstName = "Bob";
record.LastName = "Brady";

DataPortal portal = new DataPortal();
portal.Execute( record.Save() );

Now the record is informed by the portal that it has been saved to the DB. Then I do:

record.FirstName = "Robert";

At this point, the record knows that it's been changed...and so on...same for deletes, etc. Where does Unit of Work come in?

I have been looking at DLinq lately and I'm not sure that I like the model that they've come up with. For instance, say I have 2 domain classes now (Contacts and Products) and I want to make changes to both of them but only save the changes that I've made to one of them. I'm pretty sure that I'd have to use 2 data context instance to do that.

I'd much rather do something like this:

DataPortal portal = new DataPortal();
DataResult result = portal.Execute(
  Contact.SelectAll() +

DataList<Contact> contacts = result.Set<Contact>(0);
DataList<Product> products = result.Set<Product>(1);

for each Contact c in contacts
  c.FirstName = c.FirstName.Trim();
for each Product p in products
  p.Name = p.FirstName.Trim();

// If for some reason I only want to save Contacts now, I can just do this:

portal.Execute( contacts.SaveAll() );
Scruffy McScruff Send private email
Wednesday, December 05, 2007
Unit Of Work protects you from accidentally getting two objects in one system (The program), which represents a single object in another systems (The database). So instead of retrieving an object directly from the database, you go through the uow, which acts as a cache; If the object is already loaded, it will hand you that, instead of creating a new one.
Troels Knak-Nielsen Send private email
Friday, December 07, 2007
It's a bit early for me. -- That's a description of an identity map for you.

Oh well ...
Troels Knak-Nielsen Send private email
Friday, December 07, 2007
A unit of work is like a transaction, where all registered operations and objects in the UoW have their modifications applied/saved or undone/rolled back: an all-or-nothing.

UoW is a pattern, so implementations of it can vary.

Note that "transaction" doesn't have to just be database operations.  You can have unit of work implementations that handle transactional commands. to the DB, send an email, and display a message on a status monitor -- all of which have to be applied or rolled back.

Also note that UoW implementations can be implemented to handle domain objects in different fashions.  UoW implementations can let you load objects unmanaged, can be told to ignore certain objects, etc.

As mentioned above a UoW implementation often has a cache or other mechanism to track changed objects or commands that it is managing. 

Really UoW boils down to an abstraction of a transaction with automatic management of the domain objects so it knows which ones really need to be saved, and which ones do not.  If you have objects that get into the UoW that you don't want to be saved, you need to tell the UoW to ignore them.
Dan Fleet Send private email
Friday, December 07, 2007
Thanks for your answers!! Very much appreciated.
Scruffy Send private email
Friday, December 07, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz