UnitOfWork 是否等于事务？还是不止于此？答案

【问题标题】：Is UnitOfWork equals Transaction? Or it is more than that?UnitOfWork 是否等于事务？还是不止于此？
【发布时间】：2017-02-16 00:35:31
【问题描述】：

互联网上充斥着UnitOfWork模式的信息； SO也不例外。

我还是不明白。据我了解UnitOfWork = Transaction in DB。就这样;不多也不少。

这对吗？

我的困惑是由于它在不同的ORMs 中是如何实现的。 NHibernate 使用 ISession 不仅仅是 Transaction。 Dapper 一切交给你。

我的问题只是关于设计模式，不考虑任何ORM 或技术。

如果不仅仅是Transaction，请解释一下。

编辑 1

参考@David Osborne 在回答中建议的this 链接。

工作单元跟踪您在业务期间所做的一切可能影响数据库的事务。完成后，它会计算结果是改变数据库需要做的所有事情你的工作。

所以这意味着UnitOfWork 是DBTransaction 还有更多。

以下是它的额外职责：-

虽然上面引用中没有明确提到，但它也可以控制查询的批处理。

我现在的理解正确吗？

【问题讨论】：

我会说这取决于您的用例以及您的 UnitOfWork（又名 CreateCustomer、MakeBooking、CreateInvoice、...）应该做什么......我在一次交易中使用这种方式，但是一个工作单元也可以是多个事务。如果不止一个，那么您必须控制交易的回滚/恢复。

【解决方案1】：

它originates，AFAIK，因为需要 ORM 工具来跟踪逻辑/业务事务期间对象的 [持久性] 状态。

工作单元如何管理这一点，以及它与底层存储技术和存储对象的关系，是一个实现细节。

中间有许多 SQL 语句的数据库事务也可以说是一个工作单元。但是，我认为主要区别在于模式中定义的工作单元已将该级别的详细信息抽象到对象级别。

【讨论】：

【解决方案2】：

UnitOfWork 是一个商业交易。不一定是技术交易（db 交易），但通常与技术交易相关。

维护受业务事务影响的对象列表，并协调更改的写入和并发问题的解决。

它没有定义更改的写入方式和存储类型。

一个应用程序可能会将更改写入一个

UnitOfWork（业务事务）收集对业务对象的更改并确保其他业务事务只会看到有效的业务对象。

例如当您的应用程序执行一个用例时，它会修改业务对象。如果两个业务事务（通常是用例）并行执行，您的应用程序必须注意每个业务事务执行的更改以及其他业务事务将看到它们的时间。

从技术上讲，这通常是使用数据库事务来完成的。因此，一个工作单元通常是一个数据库事务。

使用 ORM 框架来处理持久性的应用程序通常在单词单元和数据库事务之间具有一对一的关系。因此，工作单元和数据库事务之间的区别通常与开发人员无关。

【讨论】：