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

Question

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

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

它是否正确？

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

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

如果不仅仅是Transaction,请解释如何.

编辑1

参考此链接为在@大卫奥斯本答案建议.

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

因此,这意味着UnitOfWork是DBTransaction 和更多.

以下是其他责任: -

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

我的理解现在正确吗？

Answer 1

A UnitOfWork是商业交易.不一定是技术交易(数据库交易),但通常与技术交易挂钩.

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

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

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

一个UnitOfWork(业务事务)收集变化的业务对象,并确保其他商业交易将只能看到有效的业务对象.

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

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

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

Answer 2

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

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

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