When I worked at new project and we adopted EJB 3 as O/R Mapping tool. Some developers think we don’t need DAO layer. They do like this:

EntityManager em = …
doService(MyEntity model){
//do businees logic for model
……
em.persist(model);
}

But this way will mix your business logic and your model persistent. If you have DAO layer, you can write like this:

doService(MyEntity model){
//do businees logic for model
……
CubeDAO.save(model);
}

CubeDAO includes findById(), save(), delete(),findByName(). Other services can call CubeDAO and reuse it. By the way, you can write JUnit test for DAO.
Also DAO layer can help you audit and loose coupling your design.

I list some examples to demonstrate this whole design concept.

1. Design enterprise applications with the EJB 3.0 Java Persistence API

2. Separate different modules:
Such as model, service (business logic) and DAO. And you can use DI framework (Spring) and AOP to make your application modularization. See Maven2 Simple project.

3. Patterns of persistence, Part 1: Strategies and best practices for modern ORM:
This article talks about generic DAO and the authors’ experience constructing many persistence tiers has given them a clear understanding of persistence patterns and best practices.

4. Has JPA Killed the DAO?

5. Migrating JDBC Data Access Objects to use EJB3

Advertisements