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


NEW: Online Workhop Effective WebApps without Frameworks is also coming to: MUC Airport.

Airport MUC workshops: Web (SPA, PWAs, Offline, Desktop, Mobile) Applications Essentials and Effective Web Applications. No migrations. #usetheplatform

Podcast: airhacks.fm and newsletter: airhacks.news

A book about rethinking Java EE Patterns

Comments:

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