软件架构：工作单元设计模式讨论

Question

根据Martin Fowler的工作单位说明：

  

“维护一个对象列表   受商业交易的影响   协调写作的变化   和并发的解决方案   问题。“

避免

  

对数据库的非常小的调用，   最终会很慢

我在想。如果我们只是将它划分为数据库事务管理，那么不会准备语句帮助吗？

Answer 1

准备好的陈述与交易没有任何关系。

Fowler所指的是网络延迟：如果您来回访问数据库，每次都会产生网络延迟。

这个问题有两个混淆在一起的想法：交易和批次。将多个数据库操作一起批处理并将它们全部发送到要处理的数据库也可以解决Fowler所说的问题。

你真正关心哪一个？

Answer 2

良好的数据访问层实现将为您完成此任务。例如，Hibernate / NHibernate可以推迟刷新更改，直到事务结束，或者显式请求刷新更改。或者，您可以使用乐观锁定在一个事务中获取数据并将更改存储在另一个事务中。这可以避免长时间的数据库事务。

如果您正在滚动自己的访问层，则可以将批处理添加到JDBC连接，以减少许多小型更新/插入请求的延迟开销。即便如此，我认为这种模式是一个好主意，因为它可以很好地概述一个地方的所有变化。因此，您可以在数据库事务中快速提交所有更改，而不是在业务事务的持续时间内对数据库进行写入 - 这可能需要很长时间，而长长的数据库事务通常不是好主意。

PreparedStatements与这种模式是正交的 - 它们既不直接帮助也不阻碍。该模式是关于减少网络延迟和短事务，以及概述业务操作中的所有实体更改。

Answer 3

模式比数据库更通用。每当您可以将多个小型操作捆绑到一个时，工作单元模式可能适用。

例如，考虑一个AJAX应用程序，您希望通知服务器您在客户端上执行的某些操作。您可能希望将这些操作捆绑到一个更大的操作中。服务器可能会也可能不会将数据传递到数据库。

在服务器端，一个工作单元可能必须将数据保存在数据库中并将其推送到使用相同数据的另一个客户端。

需要注意的关键是“业务交易”和数据库交易是两回事。