UnitOfWork等于Transaction吗？还是不止于此？

Question

互联网上充满了关于UnitOfWork模式的信息;即便如此也不例外。

我仍然不明白它。在我的理解UnitOfWork = Transaction in DB。就这样;仅此而已。

它是否正确？

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

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

如果它不仅仅是Transaction，请解释如何。

编辑1

参考@ David Osborne的回答中提到的this链接。

工作单元会跟踪您在业务事务中可能影响数据库的所有操作。完成后，它会计算出因工作而需要更改数据库的所有操作。

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

以下是其他责任： -

• 维护您在本次工作中更改，插入和删除的状态。
• 根据此状态，在工作完成后修改数据库。

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

我的理解现在正确吗？

Answer 1

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

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

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

Answer 2

UnitOfWork是一项商业交易。不一定是技术交易（数据库交易），但通常与技术交易挂钩。

在enterprise application patterns中，它被定义为

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

它没有定义如何编写更改，也没有定义存储类型。

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

• 使用SQL的数据库
• 文件系统使用流
• 使用http请求的持久性服务
• 使用方法调用分布式缓存甚至内存存储

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

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

从技术上讲，这通常使用db事务完成。因此，工作单元通常是db事务。

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