Java EE 6 - 持久域对象模式 - 成功了吗？

Question

我有一个使用 POJO 的中等复杂应用程序，现在将其迁移到 EJB3.1，以便可以在线部署、通过 REST 服务访问并受益于容器环境（持久性是最重要的，但事务将是最重要的）也很有用）。

自从 J2EE 时代以来，我一直远离 Java EE，并且正在努力解决实体 bean 的“丢失”问题。我花了一段时间才意识到 EJB3.1 中的实体实际上并不是旧意义上的 Bean... :) 我已经阅读了许多 EJB3 书籍，包括 O'Reilly Enterprise JavaBeans 3.1“手册”，所有这些都解释了EJB3 的概念和组件，但不是实现模式选项。

在我寻找 Java EE 6 模式的研究和调查中，我更喜欢 Adam Bien 的方法——尤其是“持久域对象”(PDO) 模式（在他的书中，但也在这里总结：http://download.java.net/general/podcasts/real_world_java_ee_patterns.pdf），似乎与我当前的 POJO 应用程序提供了最少的复杂性和最大的协同作用。 PDO 也与传统的面向对象的哲学和方法紧密结合，真的很吸引我。

与其重新引发关于 PDO 的辩论，我很想听听已经实施它的人的意见，以及哪些工作有效，哪些地方遇到了困难。特别是，我想了解您如何将 从 JPA 实体调用到容器中的其他服务（例如调用无状态会话 bean 等）。

我也很想知道是否有 PDO 模式的替代方案允许我维护应用程序结构（使用多态性等），而不必为我的模型中的每个类创建会话 bean 和 JPA 实体。 （我不想这样做，部分原因是重构所有单元和集成测试需要大量练习，部分原因是——据我所知——我最终会尝试复制我的 1toMany 等对象关系在我的会话 bean 中，这似乎很疯狂）。

有没有人有任何经验可以分享 - 或者如果你想指出我是个白痴，并且错过了 Java EE 6 中的一些基本内容，也将是“受欢迎的”:)

TIA

Answer 1

没有回复，所以也许我是唯一一个这样做的人；）对于其他寻找指针的人，我发现：

• 您的对象模型需要进行重大修改。您不能使用地图或 像在非 JPA 应用程序中一样的接口列表，因为 JPA 不能 “处理”接口，您需要持久化（抽象）类。 Hibernate 有一个 @Any 和 @ManyToAny 注释，但是开销 （性能、功能和编码）是（恕我直言）重要的。如果 你可以实现一个可怕的抽象类层次结构，那么你应该这样做。 呸！

• 如果您有一个模糊复杂的对象模型（对象之间的关系超过六个），您最终会在 JPA 引擎生成的 SQL 代码中使用大量的 JOIN 命令。我在某处读到 >6 JOINS 会给数据库带来很高的负载（我敢肯定，这只是一个经验法则）。 MySQL 有 61 个连接的硬限制。听起来很疯狂，你肯定从来没有打过吗？！如果你有一个抽象的对象层次结构和一些对象之间的关系，它很快就会加起来！

我还没有找到解决第一个“问题”的方法。插入大量抽象基类而不是接口感觉是错误的，但据我所知，这是不可避免的。如果没有请告诉我！

第二个问题可以通过对对象关系使用惰性获取来管理，或者通过使用 Adam 的网关模式和扩展的持久性会话（而不是在每次调用时加载和保存模型的无状态会话 bean）来管理。到目前为止，我将使用后者——但还没有到可以对内存和数据库使用情况进行负载测试的地步。我们拭目以待！