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 :-).


Web Apps, SPA, PWA with vanilla Java Script (ES 6+), CSS 3 and WebStandards only. As simple as possible, but not simpler. See you at: (Progressive) Web apps, Single Page Apps and WebStandards airhacks workshops at MUC airport, Winter Edition

airhacks.fm the podcast:

Stay in touch: airhacks.news.

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
realworldpatterns.com
...the last 150 posts
...the last 10 comments
License