Unit of Work Pattern in .Net

Question

Does anyone have any concrete examples of a simple Unit of Work pattern in C# or Visual Basic that would handle the following scenario?

I'm writing a WinForms application in which a customer can have multiple addresses associated with it. The user can add, edit and delete addresses belonging to the customer before the customer is saved back to the database. Therefore, at the time of saving, all the original addresses need to be deleted from the database and the new addresses added in a single transaction.

Answer 1

It sounds like implementing repositories would work really well here. There are good concrete examples in Java that you could port to C# or Visual Basic. Fowler's Patterns of Enterprise Application Architecture has a good discussion with examples in Java. Domain-Driven Design has a deeper discussion if you wanted more theory.

Answer 2

Here's a post that touches on UOW but in the context of a web app:

http://www.mindscape.co.nz/blog/index.php/2008/05/12/using-the-unit-of-work-per-request-pattern-in-aspnet-mvc/

Basically, you want to be using an IdentityMap to keep track of all the objects you have loaded (and any new ones) and you also need to keep track of each objects state: New, Modified, Deleted etc. At flush time, enumerate the map and perform the database work as appropriate.

I would seriously consider taking a look at an ORM such as LightSpeed before building this yourself.

Therefore, at the time of saving, all the original addresses need to be deleted from the database and the new addresses added in a single transaction

Any reason you are doing this rather than updating existing records?

Answer 3

Actually. In a WinForms context, you might want to look at Linq 2 SQL.
Basically, when the user starts editing data, you assign that "edit session" a DataContext object. All data operations are handled by this conext, both retrieve and save.
When the user is done, do a DataContext.SubmitChanges(), and all your edits should be saved as well.

That should be it.

Answer 4

Repositories seems to be the way forward. Answer 1 wasn't helpful, as this is a .NET 2.0 project, not .NET 3.5, but then I didn't specify which version of the framework I was using in the question. Answer 2 was interesting, but tied to a 3rd party ORM, which I don't have, so I've accepted Dominic's answer as the best general approach.

Answer 5

so I've accepted Dominic's answer as the best general approach.

Although useful, the Repository pattern has nothing to do with your question.

Answer 6

There is a great article about how to use Unit of Work with Repository pattern in your model.

Using Repository and Unit of Work patterns with Entity Framework 4.0