DAO's as EJB's. You are doing it wrong...

You will realise that there are tutorials on the web that shows, by example, the implementation of DAO's using the modern Java EE (please, it's no more J2EE) technologies (annotations and CDI). What I find strange, however, is that many of these DAO examples/tutorials are designed to be EJB's as well (particularly Stateless Session Beans). Even Apache, themselves, have a documentation that clearly makes a DAO as an EJB on their TomEE site.

This form of adaptation has crept, also, in business production applications that runs today (shocking, I know and it is still a practice done today by senior developers and architects). There is no separation between the (business) logic tier and the data tier (if you are creating a system using a multi-tier architecture). From my experience, developers do understand how to create DAO's and EJB's from examples that exists on the web, copy-paste the idea from the example and adapt it to their application requirement. As I said on my older post, many do not understand what the EJB container is, what it does and how it manages session beans (do you blame them?)

If you are creating a multi-tier system, you will realize that each tier is maintained as an independent module. This means each module is not dependent on other modules. The advantage of this is that each module can be created and/or deployed on/for different platforms and if each module is designed by contract, communication between each platform can occur between interfaces.

These are my reasons to why I discourage DAO's as EJB's: 

• EJB's were designed to encapsulate business logic, DAO's were designed to encapsulate data to its persistence layer. I have read arguments that EntityManager is DAO pattern itself. Granted, DAO has been designed to form an ORM approach, the only different between DAO and EntityManager is that EntityManager exposes mechanism to make calls to the persistence layer, (e.g., a Getting a SQL Connection from EntityManager or creating native query by calling EntityManager.createNativeQuery(String sqlQuery);). DAO was designed to encapsulate this mechanism. The EJB should never know where the data is stored and how it is managed, as long as it can request manipulate and pass the data to the DAO to be stored, it's happy.
• High coupling: The business logic and data persistence are so dependent on one another that a change on the business logic might/will affect the way data is persisted and vice-versa. High coupling classes/modules are bad classes/modules as an independent change to a class/module is not possible without affecting the other dependent classes/modules.

There are various more reasons but I believe you are smart enough to figure it out (please leave your comment below and state whether you agree and disagree to my statement). 

If I (strongly?) disagree on blending DAO's as EJB's, what is my recommended approach? Simple, create a data tier (such as DAO's) and Inject it, thanks to CDI (Contexts and Dependency Injection).

Injecting DAO's

Injecting DAO's is an alternative approach of requesting entity DAO's. For one, you can eliminate DAOFactory completely. 

Here are the steps to achieve DAO injection: 

• First create a generic DAO interface and relevant subclasses that is tied to a persistence strategy (e.g. JDBCDAO for JDBC DAO, HibernateDAO for using Hibernate Session strategy, JPADAO for using EntityManager as persistence strategy).
• For each entity, create a DAO entity interface that will provide methods that only return the entity requested. E.g., a CustomerDAO will only return a Customer entity.
• You can used the @Named qualifier to specify the implementation of the DAO and finally injecting by the named qualifier.
• An alternative approach that I took is to create 3 types of qualifiers: @HibernateDAO (used for DAO's that uses Hibernate Session), @JPADAO (for JPA persistence) and @JDBCDAO (for JDBC Connection).

It's easy to write a blog, but it's better showing an example (which works):

The DAO interface:

The DAO Implementation:


Note: The class is annotated with @JPADAO. This is the qualifier annotation that we specify for interface injection.

To create a custom CDI qualifier, create a custom annotation and annotate it with @Qualifier. Alternatively, if you're using Eclipse IDE (Eclipse Kepler and newer), you select the option to create a custom qualifier.

Here is the custom @JPADAO (see that it has the @Qualifier annotation, making it a CDI qualifier).



The BaseJPADAO is the DAO class that returns the EntityManager, contained from the persistence unit.


Finally, inject!!!

On my CustomerServiceEJB, I inject the DAO by interface and specifying which type of DAO I want.

And it's this simple. This runs wonderfully on my environment (Java EE 7 with Widfly 8.x). The EJB has no clue of the persistence mechanism of how the entities are stored, nor does it need to care. Since this was coded using a design by contract approach, changes to my DAO's won't affect the EJB at all, unless the interface changes and breaks the contract.

I hope this helps those who are designing a system with a multi-tier architecture.