互联网上充满了关于UnitOfWork模式的信息;即便如此也不例外。
我仍然不明白这件事。据我所知UnitOfWork = Transaction in DB。就这样;仅此而已。
这是对的吗？
我的困惑在于它是如何在不同的ORM中实现的。 NHibernate使用ISession不仅仅是Transaction。 Dapper将一切留给您。
我的问题是关于设计模式，不考虑任何ORM或技术。
如果不仅仅是Transaction，请解释如何。
修改1
@David Osborne在回答中建议的this链接。
工作单元会跟踪您在业务中所做的一切 可能影响数据库的事务。当你完成时，它会有所体现 结果需要做的一切都是为了改变数据库 你的工作。
因此，这意味着UnitOfWork为DBTransaction 且更多。
以下是其他责任： -
维持您在本次工作中更改，插入，删除的状态。
根据此状态，在工作完成后修改数据库。
虽然上面引用中没有明确提及，但它也可以控制查询的批处理。
我的理解现在正确吗？
答案 0 :(得分：6)
UnitOfWork是商业交易。不一定是技术交易（数据库交易），但通常与技术交易挂钩。
在enterprise application patterns中，它被定义为
维护受业务事务影响的对象列表，并协调写入更改和解决并发问题。
它没有定义如何编写更改，也没有定义存储类型。
applcation可能会将更改写入
UnitOfWork（业务事务）收集对业务对象的更改，并确保其他业务事务只能看到有效的业务对象。
E.g。当您的应用程序执行用例时，它会修改业务对象。如果并行执行两个业务事务（通常是用例），则应用程序必须关注每个业务事务执行的更改以及其他业务事务将看到它们的时间。
从技术上讲，这通常是使用db事务完成的。因此，工作单元通常是数据库事务。
使用ORM框架处理持久性的应用程序通常在单词单元和db事务之间具有一对一的关系。因此，工作单元和数据库事务之间的差异通常与开发人员无关。
答案 1 :(得分：3)
它是originates，AFAIK，需要ORM工具来跟踪逻辑/业务事务中对象的[持久性]状态。
工作单元如何管理它，以及它与底层存储技术和存储对象的关系是一个实现细节。
中间有许多SQL语句的数据库事务，可以说也是一个工作单元。但是，我认为关键的区别在于，模式中定义的工作单元已将该详细程度抽象为对象级别。