EAO

in EAO DP, JPA Entity & POJO (Manager) is used; I got confused that why I need this. Because if I use previous way (Entity access by EntityManager(SB)), I can use DI to inject EM & can have CMT.

Next thing in ch. is Session Bean as EAO (back to suquare one).

I am missing one thing, how accessing JPA Entity, in ch. 9 differs from ch. 12 ?
Is purpose of introduction of EAO in ch. 12, is to tell us that we used EAO in ch. 9; or to introduce a DP?

thanks...

Hong Anderson

Ranch Hand

Posts: 1936

posted 7 years ago

Deepika Joshi wrote: in EAO DP, JPA Entity & POJO (Manager) is used; I got confused that why I need this. Because if I use previous way (Entity access by EntityManager(SB)), I can use DI to inject EM & can have CMT.

I'm not sure what you confused, but using DAO or EAO will abstract persistent layer, allow you to change implementation, for example you might change to use JDBC or iBATIS, or in extreme cases you might change to not use RDBMS (like change to use OODBMS, XML Database, XML Repository, etc.).

Please feel free to ignore the EAO stuff Debu has put in. I asked him to simply use a stateless session bean with an injected Entity manager and call the object a DAO like everyone else.

He felt a need to invent his own terms and insisted on not using an EJB at the DAO layer to try to avoid any possible criticism from the usual suspects (he even mentions this rationale briefly in the chapter). I have seen no pitfalls and several benefits in using session beans at the DOA layer, not to mention the simplicity in avoiding the complicated EAO code Debu has.

If you are very averse to using EJB in the DAO layer, a much better option than Debu's convoluted code is to use Seam, JCDI (in Java EE 6), Spring or Guice beans in the DAO layer. All of them support simple injection via @PersistenceContext without other EJB services such as transactions, security, pooling or component thread-safety.