工作单元模式是一种在上下文中跟踪域上所有操作并在完成您的（可能）复杂逻辑时一次性应用它们的方法。
当与 ORM（例如 NHibernate）一起使用时，最好使用共享 ISession（或 Linq 2 Sql 中的 DataContext）来实现工作单元，该共享 ISession（或 Linq 2 Sql 中的 DataContext）用于对底层数据库的每个操作。
正确实施可能很棘手，尤其是在处理服务器应用程序时，主要是 ASP.Net MVC 或 ASP.Net Webforms。
我已经涉足了 Rhino.Commons（面向 NHibernate）中的实现，并且我知道其他几个，但没有很好地掌握它们的优点和缺点。
最常用的是什么，以及如何将它们无缝集成到 ASP.Net MVC（或 WebForms，但我最感兴趣的是 MVC）中？
更新：我在回复后看到了这个（ unit-of-work-pattern-in-net ）。
也许 System.Transactions.Transaction 是你所追求的。
工作单元是几年前最初应用于基于大型机的应用程序的术语。这些应用程序将执行一系列步骤。如果任何一个步骤失败，数据库将回滚到之前的“同步点”。该应用程序将在成功完成工作单元中的所有步骤后记录一个新的同步点。这些步骤表现得像一个单元。
这个比喻已经演变，因此在 .NET 中，我们有了一个 Transaction 构造。在事务范围内对可恢复数据存储执行的工作作为一个单元执行，具有 ACID 属性。这些数据存储的示例可能是：任何现代 RDBMS、像 MSMQ 这样的排队系统，或者在 Windows 上，文件系统或注册表（通过 KTM）。当事务解决时，它要么提交要么回滚所有事务存储上的所有操作。
我不知道 nHibernate 或 ISession 构造。但是如果您使用传统意义上的“工作单元”一词，那么我认为您想要的是事务。
至于将事务集成到 ASP.NET MVC 中 - 不确定这意味着什么。Transaction 不关心 UI 模型是什么，也不关心您如何设计 UI 流控制。如果您更新数据库（我想是“模型”），那么您可以选择将该更新包含在事务中。仅当您作为单个事务的一部分进行多次更新时才真正有意义。另一方面，您不想让交易长时间保持打开状态。对数据库的锁定将导致争用，从而导致吞吐量下降。