What are the .net reference implementations of the Unit of Work pattern ?

Question

Possible Duplicates:
unit-of-work-pattern-in-net
rhinocommons-unitofwork-question-with-asp-net-mvc

The Unit of Work pattern is a way to keep in a context to track all the actions on your domain and to apply them all at once when your - possibly - complex logic is done.

When used with an ORM (NHibernate for instance), it is considered good practice to implement the unit of work with a shared ISession (or DataContext in Linq 2 Sql) used for every action to the underlying db.

It can be tricky to implement right, especially when dealing with server applications, mainly ASP.Net MVC or ASP.Net Webforms.

I've dabbled with the implementation in Rhino.Commons (geared towards NHibernate) and I know of several others, without a good grasp of what are the upsides and downsides of them.

What are the most commonly used, and how to integrate them seamlessly in ASP.Net MVC (or WebForms but I'm mostly interested in MVC) ?

Answer 1

Update: I saw this (unit-of-work-pattern-in-net) after responding.

Maybe System.Transactions.Transaction is what you are after.

Unit-of-Work is a term that was originally applied to Mainframe-based applications years ago. The apps would perform a series of steps. If any one of the steps failed, the database would be rolled back to the previous "syncpoint". The app would record a new syncpoint after successfully completing all the steps in a unit of work. The steps behaved like a unit.

The metaphor has evolved so that in .NET, we have a Transaction construct. Work performed on recoverable data stores within the scope of a Transaction is performed as a unit, with ACID properties. Examples of those data stores might be: any modern RDBMS, a queuing system like MSMQ, or, on Windows, the filesystem or the Registry (via KTM). When the transaction resolves, it either commits or rolls back all the operations on all the transactional stores.

I don't know about nHibernate or the ISession construct. But if you are using the term "unit of work" in the traditional sense, then I think what you want is a transaction.

As for integrating transactions into ASP.NET MVC - not sure what that would mean. The Transaction does not care what the UI model is, or how you've designed the UI flow control. If you update a database (I suppose the "model"), then you have the option to include that update in a transaction. Really makes sense only if you have multiple updates, as part of a single transaction. On the other hand you do not want to allow transactions to remain open for lengthy periods. the locking on the database will cause contention and a consequent drop in throughput.