The 'flexibility' afforded by working with Plain Old Java Objects is bought at a price, namely the use of introspection.
The use of a system such as POEM has the disadvantage that, due to Java's lack of multiple inheritance, you have used your one opportunity to inherit.
If POJOs can be avoided, and you are happy to use Persistents as your base class, then that is the best way to use POEM. However POEM enables you to persist a POJO object graph to a database, which can be useful for reporting, migrating to POEM or similar POJO to database transformations. It also enables you to re-populate an object graph from a database.
What POEM does not attempt to do is keep track of changes to the POJO such that the system can tell which is most current the POJO or the store. It is not intended as your main persistance mechanism, as it is not designed with bidirectionality in mind. You can populate a POJO from a database record and visa versa but there is no attempt at transaction handling or versioning, these issues are handled in POEM itself. To use POEM as your persistence engine, with transactions and access control then your objects should inherit from Persistent; if that is not an option then Hibernate is probably what you need.
|Requires a noArg constructor||Yes||Yes|
|Setters and getters must be public||No||Yes|
|Persist public fields||Not by default||No|
|Use existing id fields||Yes||No|
|Fields must have both a setter and a getter||No||Yes|
POEM enforces Hibernate best practice, except we do not believe that POEM's troid field should rely upon any existing id field. If your POJO has a field called id and is not an instance of Persistent then the troid column name will be poemId and your id field will be used as a normal field. The underlying database will plan queries effectively.
To persist an instance of a class:
Persistent persisted = PersistentFactory.fromInstance(getDb(), pojo);