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!