持久域对象模式
我有一个使用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
没有回复，所以也许我是唯一一个这样做的人）;对于其他寻找指针的人，我发现：
你的对象模型需要重大修改。 您不能像使用非JPA应用程序那样使用地图或接口列表，因为JPA无法“处理”接口，您需要坚持（抽象）类。 Hibernate有一个@Any和@ManyToAny注解，但开销（性能，功能和编码）是（IMHO）很重要。 如果你可以实现一个可怕的抽象类层次结构，那么你应该。 YUK！
如果您有一个模糊的复杂对象模型（对象之间超过六个关系），您将在由JPA引擎生成的SQL代码中包含LOTS JOIN命令。 我在某处读到，> 6 JOIN会给数据库带来很高的负载（我确信只是一个经验法则）。 MySQL有61个连接的硬限制。 听起来很疯狂，肯定你永远不会那么做？！ 如果你有一个抽象的对象层次结构和对象之间的一些关系，它很快会加起来！
我还没有找到解决第一个“问题”的方法。 对许多抽象基类而不是接口来说，感觉是错误的，但是据我所知，这是不可避免的。 请告诉我如果不是！
第二个问题可以通过在对象关系上使用lazy-fetch来实现，或者通过使用Adam的网关模式和扩展的持久性会话（而不是无状态会话bean在每次调用中加载和保存模型）来管理。 到目前为止，我正在使用后者 - 但还没有到可以对内存和数据库使用进行加载测试的程度。 我们拭目以待！
链接地址: http://www.djcxy.com/p/10541.html上一篇: The Persistent Domain Objects pattern
下一篇: Haskell: difference in performance from different function composition?