我是唯一一个这样做的人;）对于任何寻找指针的人，我发现：

• 你的对象模型需要主要修改。您不能使用地图或
  像非JPA应用程序中的接口列表，因为JPA不能
  handle接口，您需要持久化（抽象）类。
  Hibernate有一个@Any和@ManyToAny注释，但开销
  （性能，功能和编码）是（IMHO）的重要性。如果
  你可以实现一个可怕的抽象类层次结构，那么你应该。
  喔！




• 如果您有一个模糊的对象模型（对象之间的六个以上关系），最终将在生成的SQL代码中使用LOTS的JOIN命令由JPA引擎。我读到某个地方，> 6 JOINS给数据库带来了很大的负担（只是我确定的经验法则）。 MySQL具有61个连接的硬限制。听起来很疯狂，肯定你永远不会打那个？如果你有一个抽象对象层次结构和对象之间的几个关系，它很快就会加起来！

找到了解决第一个问题的方法。在很多抽象基类而不是接口中感觉错误，但是我看不到它是不可避免的。请告诉我，否则不能！

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

I have a moderately complex application using POJOs, and now come to migrated it to EJB3.1 so it can be deployed online, accessed through REST services and benefit from the container environment (persistence being the most major, but transactions would be useful too).

I have been away from Java EE since the J2EE days, and am struggling to get my head around the "loss" of entity beans. It took me a while to realise that Entities in EJB3.1 are not actually Beans in the old sense... :) I have read a number of EJB3 books including the O'Reilly Enterprise JavaBeans 3.1 "manual", all of which explain the concepts and components of EJB3 but not the implementation pattern options.

In my research and investigation looking for Java EE 6 patterns I'm rather taken by Adam Bien's approach - particularly the "Persistent Domain Objects" (PDO) pattern (in his book but summarised here too: http://download.java.net/general/podcasts/real_world_java_ee_patterns.pdf), which appears to offer the least complexity and most synergy with my current POJO app. PDO also closely-aligns with the traditional Object Oriented philosophies and approach, and really appeals to me.

Rather than resparking a debate over PDO, I'm interested to hear from people that have implemented it and what worked vs. where you had difficulties. In particular I'd like to find out how you made calls from JPA entities out into other services in the container (like calls to stateless session beans etc).

I'd also love to know if there are alternatives to the PDO pattern that allow me to maintain the application structure (using polymorphism etc) without having to create a session bean and a JPA entity for every class in my model. (I don't want to do that partly because of the massive exercise required to refactor all of the unit and integration tests, and partly because - as far as I can see - I'll end up trying to replicate my 1toMany etc object relationship across my session beans too which seems crazy).

Does anyone have any experiences to share - or if you'd like to point out I'm an idiot and have missed something fundamental in Java EE 6 that would be "welcome" too :)

TIA

No replies so maybe I'm the only one doing it ;) For anyone else looking for pointers, I have found:

• your object model needs major modification. You can't use Maps or Lists of interfaces as you would in a non-JPA app, because JPA can't "handle" interfaces, you need to persist (abstract) classes. Hibernate has an @Any and @ManyToAny annotation, but the overhead (performance, functionality and coding) is (IMHO) significant. If you can implement a hideous abstract class hierarchy then you should. YUK!

• If you have a vaguely complex object model (more than six relationships between objects) you will end up with LOTS of JOIN commands in the SQL code that is generated by the JPA engine. I read somewhere that >6 JOINS puts a high load on the database (just a rule-of-thumb I'm sure). MySQL has a hard limit of 61 joins. Sounds crazily high, surely you'd never hit that?! If you've got an abstract object hierarchy and a few relationships between objects it soon adds up!

I haven't found a way to get around the first "problem". It feels wrong to ram-in lots of abstract base classes instead of interfaces, but it's unavoidable as far as I can see. Please tell me if not!

The second problem can be managed by using lazy-fetch on object relationships, or by using Adam's Gateway pattern and extended persistence sessions (rather than stateless session beans loading and saving the model on every call). I'm going with the latter so far - but haven't got to a point where I can load-test on the memory and database usage yet. We'll see!