Have wondered about pojos for sometime and I finally put my curiousity to rest. from Mike Clark’s blog
POJO is an acryonym for Plain ‘Ol Java Object. It’s a rather old-school concept, I realize. When gazing upon the totem pole of recent technology, you’ll find it at the bottom. You can’t directly access one across the network, replicate its state across a cluster, or expect it to save itself to a database. And until recently, a POJO wasn’t even given the respect inherent in being called by an acronym. Any technology worth its salt these days must have an acronym, right?
POJOs are perfectly happy going about their humble duties in J2SE squalor. They prefer not to be bothered by those megalomaniacs living large in the J2EE world. Yet often times they get locked up inside some pompous component that proceeds to drag them around hither and yon. Their cry for freedom is unmistakable. The last time I heard one writhing in pain it was a captive of a session bean. I wanted to set it free, if only for my own selfish desire to easily test it. Yet it was difficult to discern where the EJB plumbing ended and the POJO began. Indeed, there was no way to get at it without first passing through the gates of its captor. I did eventually manage to unshackle it, and it went on to do great things. How it became tangled up with the session bean I’ll never know. I do know that it wanted to be tested, if only for its own selfish desire to live in isolation from the beginning.
I think this will finally be the year when POJOs rise up against the oppression of their J2EE tyrants. The world will come to realize that J2EE is nothing more than a layering technology. Servlets, session beans, and message consumers alike should simply decorate POJOs. Indeed, these J2EE components are merely ambassadors rolling out red carpets for other technologies to approach the POJO. And yet unadorned by these decorations, a POJO has value in its own right as the keeper of business logic.