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

没有回复，所以也许我是唯一一个这样做），表示任何人找球，我发现：

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

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

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

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