1. Overview
The Data Access Object (DAO) pattern is a structural pattern that allows us to isolate the application/business layer from the persistence layer (usually a relational database, but it could be any other persistence mechanism) using an abstract API.
The functionality of this API is to hide from the application all the complexities involved in performing CRUD operations in the underlying storage mechanism. This permits both layers to evolve separately without knowing anything about each other.
In this tutorial, we’ll take a deep dive into the pattern’s implementation, and we’ll learn how to use it for abstracting calls to a JPA entity manager.
2. A Simple Implementation
To understand how the DAO pattern works, let’s create a basic example.
Let’s say that we want to develop an application that manages users. To keep the application’s domain model completely agnostic about the database, we’ll create a simple DAO class that will take care of keeping these components neatly decoupled from each other.
2.1. The Domain Class
As our application will work with users, we need to define just one class for implementing its domain model:
public class User {
private String name;
private String email;
// constructors / standard setters / getters
}
The User class is just a plain container for user data, so it doesn’t implement any other behavior worth stressing.
Of course, the most relevant design choice that we need to make here is how to keep the application that uses this class isolated from any persistence mechanism that could be implemented at some point.
Well, that’s exactly the issue that the DAO pattern attempts to address.
2.2. The DAO API
Let’s define a basic DAO layer, so we can see how it can keep the domain model completely decoupled from the persistence layer.
Here’s the DAO API:
public interface Dao<T> {
Optional<T> get(long id);
List<T> getAll();
void save(T t);
void update(T t, String[] params);
void delete(T t);
}
From a bird’s eye view, it’s clear to see that the Dao interface defines an abstract API that performs CRUD operations on objects of type T.
Due to the high level of abstraction that the interface provides, it’s easy to create a concrete, fine-grained implementation that works with User objects.
2.3. The UserDao Class
Let’s define a user-specific implementation of the Dao interface:
public class UserDao implements Dao<User> {
private List<User> users = new ArrayList<>();
public UserDao() {
users.add(new User("John", "john@domain.com"));
users.add(new User("Susan", "susan@domain.com"));
}
@Override
public Optional<User> get(long id) {
return Optional.ofNullable(users.get((int) id));
}
@Override
public List<User> getAll() {
return users;
}
@Override
public void save(User user) {
users.add(user);
}
@Override
public void update(User user, String[] params) {
user.setName(Objects.requireNonNull(
params[0], "Name cannot be null"));
user.setEmail(Objects.requireNonNull(
params[1], "Email cannot be null"));
users.add(user);
}
@Override
public void delete(User user) {
users.remove(user);
}
}
The UserDao class implements all the functionality required for fetching, updating, and removing User objects.
For simplicity’s sake, the users List acts like an in-memory database, which is populated with a couple of User objects in the constructor.
Of course, it’s easy to refactor the other methods, so they can work, for instance, with a relational database.
While both the User and UserDao classes coexist independently within the same application, we still need to see how the latter can be used for keeping the persistence layer hidden from application logic:
public class UserApplication {
private static Dao userDao;
public static void main(String[] args) {
userDao = new UserDao();
User user1 = getUser(0);
System.out.println(user1);
userDao.update(user1, new String[]{"Jake", "jake@domain.com"});
User user2 = getUser(1);
userDao.delete(user2);
userDao.save(new User("Julie", "julie@domain.com"));
userDao.getAll().forEach(user -> System.out.println(user.getName()));
}
private static User getUser(long id) {
Optional<User> user = userDao.get(id);
return user.orElseGet(
() -> new User("non-existing user", "no-email"));
}
}
The example is contrived, but it shows, in a nutshell, the motivations behind the DAO pattern. In this case, the main method just uses a UserDao instance to perform CRUD operations on a few User objects.
The most relevant facet of this process is how UserDao hides from the application all the low-level details on how the objects are persisted, updated, and deleted.
3. Using the Pattern with JPA
There’s a general tendency among developers to think that the release of JPA downgraded to zero the DAO pattern’s functionality, as the pattern becomes just another layer of abstraction and complexity implemented on top of the one provided by JPA’s entity manager.
Unquestionably, in some scenarios this is true. Even so, sometimes we just want to expose to our application only a few domain-specific methods of the entity manager’s API. In such cases, the DAO pattern has its place.
3.1. The JpaUserDao Class
With that said, let’s create a new implementation of the Dao interface, so we can see how it can encapsulate the functionality that JPA’s entity manager provides out of the box:
public class JpaUserDao implements Dao<User> {
private EntityManager entityManager;
// standard constructors
@Override
public Optional<User> get(long id) {
return Optional.ofNullable(entityManager.find(User.class, id));
}
@Override
public List<User> getAll() {
Query query = entityManager.createQuery("SELECT e FROM User e");
return query.getResultList();
}
@Override
public void save(User user) {
executeInsideTransaction(entityManager -> entityManager.persist(user));
}
@Override
public void update(User user, String[] params) {
user.setName(Objects.requireNonNull(params[0], "Name cannot be null"));
user.setEmail(Objects.requireNonNull(params[1], "Email cannot be null"));
executeInsideTransaction(entityManager -> entityManager.merge(user));
}
@Override
public void delete(User user) {
executeInsideTransaction(entityManager -> entityManager.remove(user));
}
private void executeInsideTransaction(Consumer<EntityManager> action) {
EntityTransaction tx = entityManager.getTransaction();
try {
tx.begin();
action.accept(entityManager);
tx.commit();
}
catch (RuntimeException e) {
tx.rollback();
throw e;
}
}
}
The JpaUserDao class is capable of working with any relational database supported by the JPA implementation.
Furthermore, if we look closely at the class, we’ll realize how the use of Composition and Dependency Injection allows us to call only the entity manager methods required by our application.
Simply put, we have a domain-specific tailored API, rather than the entire entity manager’s API.
3.2. Refactoring the User class
In this case, we’ll use Hibernate as the JPA default implementation, thus we’ll refactor the User class accordingly:
@Entity
@Table(name = "users")
public class User {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private long id;
private String name;
private String email;
// standard constructors / setters / getters
}
3.3. Bootstrapping a JPA Entity Manager Programmatically
Assuming that we already have a working instance of MySQL running either locally or remotely and a database table “users” populated with some user records, we need to get a JPA entity manager, so we can use the JpaUserDao class for performing CRUD operations in the database.
In most cases, we accomplish this via the typical “persistence.xml” file, which is the standard approach.
In this case, we’ll take an “xml-less” approach and get the entity manager with plain Java through Hibernate’s handy EntityManagerFactoryBuilderImpl class.
For a detailed explanation on how to bootstrap a JPA implementation with Java, please check this article.
3.4. The UserApplication Class
Finally, let’s refactor the initial UserApplication class, so it can work with a JpaUserDao instance and execute CRUD operations on the User entities:
public class UserApplication {
private static Dao<User> jpaUserDao;
// standard constructors
public static void main(String[] args) {
User user1 = getUser(1);
System.out.println(user1);
updateUser(user1, new String[]{"Jake", "jake@domain.com"});
saveUser(new User("Monica", "monica@domain.com"));
deleteUser(getUser(2));
getAllUsers().forEach(user -> System.out.println(user.getName()));
}
public static User getUser(long id) {
Optional<User> user = jpaUserDao.get(id);
return user.orElseGet(
() -> new User("non-existing user", "no-email"));
}
public static List<User> getAllUsers() {
return jpaUserDao.getAll();
}
public static void updateUser(User user, String[] params) {
jpaUserDao.update(user, params);
}
public static void saveUser(User user) {
jpaUserDao.save(user);
}
public static void deleteUser(User user) {
jpaUserDao.delete(user);
}
}
Even when the example is pretty limited indeed, it remains useful for demonstrating how to integrate the DAO pattern’s functionality with the one that the entity manager provides.
In most applications, there’s a DI framework, which is responsible for injecting a JpaUserDao instance into the UserApplication class. For simplicity’s sake, we’ve omitted the details of this process.
The most relevant point to stress here is how the JpaUserDao class helps to keep the UserApplication class completely agnostic about how the persistence layer performs CRUD operations.
In addition, we could swap MySQL for any other RDBMS (and even for a flat database) further down the road, and still, our application would continue working as expected, thanks to the level of abstraction provided by the Dao interface and the entity manager.
4. Conclusion
In this article, we took an in-depth look at the DAO pattern’s key concepts, how to implement it in Java, and how to use it on top of JPA’s entity manager.
As usual, all the code samples shown in this article are available over on GitHub.