UnitOfWork 是否等于交易？或者不止于此？
Is UnitOfWork equals Transaction? Or it is more than that?
互联网上充满了关于 UnitOfWork 模式的信息；甚至SO也不例外。
我还是有些不明白。以我的理解UnitOfWork = Transaction in DB。就这样;仅此而已。
这是正确的吗？
我的困惑是由于它在不同 ORM 中的实现方式。 NHibernate 使用 ISession 不仅仅是 Transaction。 Dapper一切交给你。
我这里的问题只是关于设计模式，没有考虑任何ORM或技术。
如果不仅仅是Transaction，请说明如何。
编辑 1
参考@David Osborne 在回答中建议的 this link。
A Unit of Work keeps track of everything you do during a business
transaction that can affect the database. When you're done, it figures
out everything that needs to be done to alter the database as a result
of your work.
所以这意味着 UnitOfWork 是 DBTransaction 和更多 。
以下是其额外职责：-
维护您在此会话中更改、插入、删除的内容的状态。
基于此状态，工作完成后修改数据库。
虽然在上面的引用中没有明确提到，但它也可以控制查询的批处理。
我的理解正确吗？
它 originates，AFAIK，因为需要 ORM 工具在 logical/business 事务期间跟踪对象的 [持久性] 状态。
工作单元如何管理它，以及它与底层存储技术和存储对象的关系，是一个实现细节。
一个数据库事务，中间有许多 SQL 语句，可以说也是一个工作单元。然而，我想，关键的区别在于模式中定义的工作单元已经将该细节级别抽象为对象级别。
A UnitOfWork 是一项商业交易。不一定是技术事务（数据库事务），但通常与技术事务相关联。
在enterprise application patterns中定义为
Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.
它没有定义更改的写入方式和存储类型。
应用程序可能会将更改写入
- 数据库使用 SQL
- 使用流的文件系统
- 使用 http 请求的持久性服务
- 分布式缓存甚至使用方法调用的内存存储
UnitOfWork（业务事务）收集对业务对象的更改并确保其他业务事务只会看到有效的业务对象。
例如当您的应用程序执行用例时，它会修改业务对象。如果两个业务事务（通常是用例）并行执行，您的应用程序必须注意每个业务事务执行的更改以及其他业务事务看到它们的时间。
从技术上讲，这通常是使用数据库事务完成的。因此，一个工作单元通常是一个数据库事务。
使用 ORM 框架处理持久性的应用程序通常在单词单元和数据库事务之间具有一对一的关系。因此，工作单元和数据库事务之间的区别通常与开发人员无关。
互联网上充满了关于 UnitOfWork 模式的信息；甚至SO也不例外。
我还是有些不明白。以我的理解UnitOfWork = Transaction in DB。就这样;仅此而已。
这是正确的吗？
我的困惑是由于它在不同 ORM 中的实现方式。 NHibernate 使用 ISession 不仅仅是 Transaction。 Dapper一切交给你。
我这里的问题只是关于设计模式，没有考虑任何ORM或技术。
如果不仅仅是Transaction，请说明如何。
编辑 1
参考@David Osborne 在回答中建议的 this link。
A Unit of Work keeps track of everything you do during a business transaction that can affect the database. When you're done, it figures out everything that needs to be done to alter the database as a result of your work.
所以这意味着 UnitOfWork 是 DBTransaction 和更多 。
以下是其额外职责：-
维护您在此会话中更改、插入、删除的内容的状态。
基于此状态，工作完成后修改数据库。
虽然在上面的引用中没有明确提到，但它也可以控制查询的批处理。
我的理解正确吗？
它 originates，AFAIK，因为需要 ORM 工具在 logical/business 事务期间跟踪对象的 [持久性] 状态。
工作单元如何管理它，以及它与底层存储技术和存储对象的关系，是一个实现细节。
一个数据库事务，中间有许多 SQL 语句，可以说也是一个工作单元。然而，我想，关键的区别在于模式中定义的工作单元已经将该细节级别抽象为对象级别。
A UnitOfWork 是一项商业交易。不一定是技术事务（数据库事务），但通常与技术事务相关联。
在enterprise application patterns中定义为
Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.
它没有定义更改的写入方式和存储类型。
应用程序可能会将更改写入
- 数据库使用 SQL
- 使用流的文件系统
- 使用 http 请求的持久性服务
- 分布式缓存甚至使用方法调用的内存存储
UnitOfWork（业务事务）收集对业务对象的更改并确保其他业务事务只会看到有效的业务对象。
例如当您的应用程序执行用例时，它会修改业务对象。如果两个业务事务（通常是用例）并行执行，您的应用程序必须注意每个业务事务执行的更改以及其他业务事务看到它们的时间。
从技术上讲，这通常是使用数据库事务完成的。因此，一个工作单元通常是一个数据库事务。
使用 ORM 框架处理持久性的应用程序通常在单词单元和数据库事务之间具有一对一的关系。因此，工作单元和数据库事务之间的区别通常与开发人员无关。