Persistent Anemic Object was a best practice, now (EJB 3) it is almost an antipattern

Yesterday I checked-in a sample for the Persistent Anemic Object (PAO) "pattern" into p4j5's svn-repository. In J2EE-world the separation between the business logic and persistence was a best practice. With EJB 3 and JPA and especially more complex use cases there are no more reasons to promote the old procedural programming style. Especially interactive and object-oriented use cases are hard to realize in maintainable way (without many instanceof invocations) with an anemic persistence layer...

The PAO is just a very simple persistent structure which can be easily generated (and overwritten) from the database. It consists mainly of accessors (getters/setters) and the state - almost no methods. Because it does not contains any business logic, it can be easily generated from a database. Also the checked-in sample is generated with netbeans 5.5.1 wizzard - a typical PAO. The PAO could be a best practice in procedural SOA-world, where the persistence access is often designed as service as well as the business logic. But the SOA-way is not always easy to build and cheap to maintain :-).