如何跨多个请求（使用 Wicket 和 JPA）将实体（或其关联）附加到当前持久性上下文？

Question

我正在 Java EE 上开发基于 Wicket 的 Web 应用程序。

我试图找到一种方法来确保在 Wicket 尝试渲染任何组件之前，用作模型对象的任何实体始终附加到当前的 EntityManager。这样，当组件从其模型中获取数据时，实体可以根据需要延迟加载数据。

那里有很多教程，这里还有一些帖子，提到 LoadableDetachableModels (LDM) 作为解决方案。当我们不需要在请求之间保留任何状态时，这对我们有用。在这些情况下，每当呈现页面时，LDM 都会从数据库加载所需实体的最新版本。

然而，有时用户需要在保存数据之前通过多个步骤以有状态形式编辑数据，因此模型需要将实体保留在“未保存”状态。 LDM 将有效地消除用户在每一步中所做的更改。

到目前为止，我们一直在使用一种在需要时将实体与持久性上下文合并的模型。这是一个简化版本：

public final class DetachableMergingModel<E extends Identifiable> implements IModel<E> {

    private E entity;
    private boolean attached = false;

    public DetachableMergingModel(E entity) {
        this.entity = entity;
    }

    @Override
    public E getObject() {
        if (!attached) {
            attached = true;
            // Non-transactional method merges entity with persistence context 
            // but does not flush any data to database
            entity = getRepository().merge(entity);
            }
        }
        return entity;
    }

    @Override
    public void setObject(E entity) {
        this.entity = entity;
    }

    @Override
    public void detach() {
        // This ensures that the next call to getObject() will merge the entity with 
        // the persistence context
        attached = false;
    }
    /* ... */
}

我们的 EntityManager 由 GlassFish 注入，它跨越整个 servlet 请求，因此当实体附加到持久性上下文时，它将保持附加状态，直到页面呈现之后。

上面的模型处理实体已经被持久化并且刚刚被编辑的情况。每当页面上的组件调用此模型上的 getObject() 时，模型都会将实体与持久化上下文合并，并且我们可以自由地导航实体的整个对象图，而不会抛出任何 LazyInitializationExceptions。

但是，在实体是新的且尚未持久化的情况下，我们无法使用此模型，因为实体尚未准备好合并。当用户创建新实体并且仍然需要通过表单填充值时，通常会出现这种情况。在这种情况下，我们希望拥有相同的自由度来导航实体的对象图（因为已经设置了一些关联，例如实体的父级），而不必担心出现 LazyInitializationException。

此处描述了类似的解决方案（选项#3），但它不涵盖上述“新实体”用例。

有人遇到过这个用例吗？你是怎么解决的？有没有比通过自定义 IModel 实现更好的方法将 Wicket 与 JPA 集成？

Answer 1

在这种情况下，我通常会创建一个 DTO 来保存创建实体所需的所有数据。
如果您需要引用现有实体 - 将它们作为单独的模型传递到您的表单/面板。提交表单后，您可以：

• 执行验证
• 从已编辑的 DTO 创建一个新实体
• 注入对您存储在这些单独的 LDM 模型中的其他实体的引用。
• 持久化实体。

虽然有点麻烦，但确实有效。

跨越多个请求的对话在纯 wicket 中不可用，并且可能永远不会 - 这不是 wicket 的区域。

Seam 支持长时间对话，并且它确实支持 wicket（我从未使用过 Seam - 我无法在这方面向您提供建议）。

Answer 2

似乎是一篇旧帖子..

我希望它能对其他人有所帮助：

首先：
你的LDM有点没用，因为实体属性不是瞬态的。因此，您的实体被序列化到会话存储中，这不是 LDM 的含义。它应该最小化任何模型数据的序列化大小。

第二：
你的问题不是真正的问题，因为你需要的是你已经拥有的：
您想要准备一个跨多个页面的实体，最终存储在数据库中（某些向导等......）。现在，您的 LDM 已在客户端请求之间完全序列化到会话存储，您的实体及其编辑的数据可以承受多个请求，无需进行任何合并。一旦您的向导完成，您只需保留该孔实体即可。在实体处于最终状态之前，保留任何内容都是没有意义的（尽管它在会话存储中的请求中仍然存在）。

您甚至不需要 LDM 来实现这种功能。

只需将实体作为参数提供给下一页，用户可以在其中完成其数据。

希望你已经解决了这个问题..