design-patterns - 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 的方法——尤其是“Persistent Domain Objects”(PDO)模式(在他的书中，但也在这里总结:http://download.java.net/general/podcasts/real_world_java_ee_patterns.pdf)，它似乎提供与我当前的 POJO 应用程序的复杂性和协同性最差。 PDO 也与传统的面向对象的哲学和方法紧密结合，并且真的很吸引我。

与其重新引发关于 PDO 的辩论，我很想听听那些已经实现它的人的意见，以及什么是有效的，什么是你遇到困难的地方。我特别想知道您是如何调用电话的 来自 JPA 实体进入容器中的其他服务(如对无状态 session bean 的调用等)。

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

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

TIA

Answer 1

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

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

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

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

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