Data Access Object--Reader's Questions

Q1) If I have several services that use a common dao (to make a distinction between logic and data-access code): => is my dao still a DAO? (must I rename it otherwise?)

Data access logic is already extremely well encapsulated with an EntityManager. You don't have to rename a DAO to something else, but DAO actually does not mean anything sensible. I try to name the objects after their domain responsibilities and not technical nature. However, in my opinion your DAO is just a regular "Control".

=> should I use CDI or EJB to manage my "DAO"? Indeed, the DAO doesn't contain the slightest logic and according to EJB3 specification: “An enterprise bean typically contains business logic”.

A "DAO" is deployed as a usual CDI managed bean, except it needs services like asynchronous processing. In this case a DAO is implemented as an EJB without any interfaces.

Moreover, the DAO will only be accessed from local EJBs; therefore the DAO should not need to benefit from all EJB services. Certainly, a lighter container-management would fit better a DAO, am I right?

EJB overhead is usually negligible (stay tuned--I would like to cover the topic in one of the upcoming posts). But if you don't need additional services, you can just remove the @Stateless annotation. Less code cluttering is always good!

Q2) From my experience, we store one type of data into only one data-store. It means that if someday we switch from one data-store to another one, we need to update the data-access code but we don't need to develop an interface (because there is always only one implementation). Am I right?

It is all about Probability. How likely is the event of database vendor change? How long would it take to introduce an interface on-demand with a modern IDE?

Q3: My last question is more related to JPA: JPQL is not able to persist every kind of data into any kkind of datastores (flat file etc..), it only works for SQL-databases but SQL is already a common language. So from a provider-independence perspective; JPQL is useless, isn't it? It's just a myth, isn't it?"

It is somehow true. JPA was designed with relational DBs in mind. But checkout:

http://www.datanucleus.org

http://wiki.eclipse.org/EclipseLink/Examples/JPA/NoSQL

https://github.com/impetus-opensource/Kundera

[See also an in-depth discussion in the "Real World Java EE Patterns--Rethinking Best Practices" book (Second Iteration, "Green Book"), page 259 in, chapter "Data Access Object"]

See you at Java EE Workshops at MUC Airport!

Comments:

I didn't want to post a comment until I'm sure that I have no questions anymore. Seems to be ok for now :)
Thank you!

Regards.
Glh

Posted by Glh on February 22, 2013 at 10:12 PM CET #

Hi Adam,
Thanks for the posts on Java EE best practices. Lot has been talked about Persistence layer with JPA. Any best practices or guideline around settings for Transaction Isolation Level ? Should we explicitly set it on the container or leave it to the default and which defaults to the Database isolation levels defaults.

Any information would be helpful.

Thanks,
Pavan

Posted by Pavan Madiraju on March 20, 2013 at 05:34 PM CET #

Not at all.
I still use an abstract class with class type and ID for generic methods such findById, findAll, merge, etc, in this way I don't have to rewrite the wheel for every DAO I create

Posted by FStarred on August 29, 2019 at 12:42 PM CEST #