工作单元模式的 .net 参考实现有哪些？
工作单元模式是一种在上下文中跟踪所有操作的方法在您的域上，并在您的（可能是）复杂的逻辑完成时立即应用它们。
当与 ORM（例如 NHibernate）一起使用时，使用用于底层数据库的每个操作的共享 ISession（或 Linq 2 Sql 中的 DataContext）来实现工作单元被认为是很好的做法。
正确实施可能很棘手，尤其是在处理服务器应用程序（主要是 ASP.Net MVC 或 ASP.Net Webforms）时。
我已经涉足了 Rhino.Commons（面向 NHibernate）的实现，并且我知道其他几个，但没有很好地掌握它们的优点和缺点。
最常用的是什么，以及如何将它们无缝集成到 ASP.Net MVC（或 WebForms，但我最感兴趣的是 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) ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
也许 System.Transactions.Transaction 就是您所追求的。
工作单元这个术语最初应用于多年前基于大型机的应用程序。 这些应用程序将执行一系列步骤。 如果任何一个步骤失败，数据库将回滚到前一个“同步点”。 在成功完成工作单元中的所有步骤后，应用程序将记录新的同步点。 这些步骤就像一个整体。
这个比喻已经演变，因此在 .NET 中，我们有了一个 Transaction 构造。 在事务范围内对可恢复数据存储执行的工作作为一个单元执行，具有 ACID 属性。 这些数据存储的示例可能是：任何现代 RDBMS、MSMQ 等排队系统，或者 Windows 上的文件系统或注册表（通过 KTM）。 当事务解决时，它会提交或回滚所有事务存储上的所有操作。
我不知道 nHibernate 或 ISession 构造。 但如果您使用传统意义上的“工作单元”一词，那么我认为您想要的是事务。
至于将事务集成到 ASP.NET MVC - 不确定这意味着什么。 事务不关心 UI 模型是什么，也不关心您如何设计 UI 流控制。 如果您更新数据库（我认为是“模型”），那么您可以选择将该更新包含在事务中。 仅当您有多个更新作为单个事务的一部分时才真正有意义。 另一方面，您不希望交易长时间保持开放状态。 数据库上的锁定将导致争用并导致吞吐量下降。
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.