A question for Chris Richardson whom I assume he perfectly knows the definition of a POJO : there seems to be 2 definitions for POJO, it's either a plain old Java object, that is a normal Java class, or a Javabean class, with getters and setters.
The most definition of a Plain Old Java Object (POJO) is an object that does not implement any special interfaces (ie. interfaces defined by an infrastructure framework such as EJB).
I think its useful to extend that definition to prohibit POJOs from directly calling infrastructure framework APIs. Using this extended definition results in code that is decoupled from the infrastructure frameworks.
This has several benefits * Its easier and faster to test - no waiting for the code to deploy or dependency on things that slow down testing such as a database * Developers who have domain expertise but not infrastructure expertise can work on the code * Your code is not impacted by rapidly evolving Java infrastructure frameworks some of which change incompatibly from one version to the next.
When Java started off wasn't it all POJO's which you built your own classes. Then came the hoo-haa's about new frameworks and models which were supposed to "do everything" for the application developer. I am sure that these frameworks had its own advantages. People and corporations took these frameworks/ APIs and built a lot of applications/ services.
Now aren't we going multiple steps backwards in proclaiming POJO as the next "in" thing ?
To me, if I had written an application some 6 years ago and did NOT bother to follow the herd to convert my applications to be J2EE compliant, I am now in the world of POJOs !!! Correct me if I am wrong !
I believe after building all these complex blocks, we are claiming that "Oh! all these complexities are too much.. lets get back to the basics" Maybe there are benefits but isnt it turning the clock backwards ?
One way to look at the evolution of java frameworks:
0. No frameworks.
Your application code consists of a mixture busines logic + infrastructure logic (transactions, persistence etc) that you had to write yourself.
1. Invasive infrastructure frameworks such EJB 2.
The frameworks took care of the infrastructure issues (so you didn't have to write it yourself) but either (a) your classes had to implement special interfaces or (b) call framework APIs
2. Non-invasive frameworks/POJO-style programming
The frameworks still take care of infrastructure issues BUT very little of your code is coupled to those frameworks. For example, Spring provides transparent transaction management, Hibernate provides transparent persistence and only the small amount of DAO code has to call Hibernate APIs
Given all of the issues/benefits discussed previously I would claim that this is big step forward.
I am not sure I understand what you are saying. EJB2 is an "Invasive Framework" because you have to implement special interfaces or call framework API's? I don't disagree with that statement, but not sure I have ever thought about it that way.