如何将UnitOfWork模式与IdentityMap模式一起使用？

Question

在Martin Fowler的书中，我读到了UnitofWork和IdentityMap模式。

作者提到，将identityMap放在UnitOfWork内部是一个好主意。但怎么做呢？

据我所知，identitymap受会话限制，但作者没有提到UnitofWork

public clas Client{

     List<Order> orders;
    ...
}

每个unitOfWork实例需要多少个IdentityMap实例？

如果我们有两个并发请求呢？

Answer 1

问：UnitOfWork实例是否受会话限制？

在马丁的书的第11章中，你读到：

“一个工作单元跟踪您在可能影响数据库的业务事务期间所做的一切。完成后，它会计算出作为您工作的结果而需要进行的更改数据库的所有操作。[...]

class UnitOfWorkServlet...

   final protected void doGet(HttpServletRequest request, HttpServletResponse response)
         throws ServletException, IOException {
      try {
         UnitOfWork.newCurrent();
         handleGet(request, response);
         UnitOfWork.getCurrent().commit();
      } finally {
         UnitOfWork.html" target="_blank">setCurrent(null);
      }
   }

   abstract void handleGet(HttpServletRequest request, HttpServletResponse response)
         throws ServletException, IOException; 

在本例中，您可以将会话理解为UnitOfWork。在书的后面，他解释说：

“如果您有多个映射，明显的路径是每个类或每个表一个映射，如果您的数据库模式和对象模型相同，这会很好地工作。“

在后面的几段中，Martin解释了identitymap的位置：

现在，“业务事务”的范围可能是短暂的，例如，绑定到HTTP请求的生命期，就像Martin Fowler在上面的例子中那样，其中UnitOfWork似乎绑定到每个请求的线程本地变量。

或者“业务事务”可以包含多个请求，例如在JPA中有一个扩展持久性上下文的概念，其中JPA中的持久性上下文对应于UnitOfWork模式。在扩展的持久性上下文中，业务事务扩展的时间更长。一个典型的例子是购物车：当用户开始将项目放入购物车时，就会创建上下文/工作单元，直到用户签出购物车（提交更改）或会话过期（丢弃工作单元中的所有内容），上下文才会被清除。

现在，还有应用程序管理上下文的思想，这基本上意味着，在您认为合适的时候启动您的工作单元，在您不再需要它的时候关闭它。例如，假设您有一个桌面应用程序和一个具有隔离并发性的小型数据库（即每个用户只管理自己的数据，从不与其他用户的数据冲突）。假设用户的数据可以完美地放入计算机的内存中。在这种情况下，您可以在应用程序开始时启动UnitOfWork，并将其用作数据库的某种缓存。适当时，可以将UnitOfWork刷新到磁盘上，例如当用户单击save按钮时，但仍保持其活动状态。当用户关闭应用程序时，UnitOfWork将被丢弃。

根据到目前为止的解释，您可以有多个工作单元，其中包括以下原因：

• 每个请求一个UnitWork，如果您的应用程序处理并发请求，那么您将同时拥有多个工作实例单元。
• 每个扩展事务都有一个UnitOfWork绑定到用户的会话。如果有多个用户，则可以有多个工作单元。

然而，除了这些，我还发现了其他原因，为什么你可能希望在同一“业务交易”期间产生一个新的工作单元。