Introduction

Unless you have been living in a cave for all this long, you might have heard of the “DAO” design pattern in software development if you’re a software developer.

DAO is an acronym that stands for “Data Access Object”.

As the name implies, it is an ‘object’ that encapsulates data access operations. In object oriented programming; it is an object that allows or abstracts away the data access element from/to an external data system.

This data system can be any generic data source or can be a very specific kind of database. When this pattern arose; it was common (especially in the Java Development world) to use this as a pattern to abstract away all the database access. The database was commonly a RDBMS (Relation Database Management System) such as MySQL, Oracle RDBMS, PostgreSQL, DB2 etc. Nowadays, is it not surprising that the DAO pattern is used to abstract away database operations to any other database systems like the NoSQL category of databases such as MongoDB, Apache Cassandra, Redis, Neo4J etc.

This pattern has existed for a very long time and as such i am going to show you an example in Java which demonstrates abstraction over a relational database. For other object-oriented programming languages the code would be similar.

Structure — Class Diagram

Here is a class diagram of the DAO design pattern:

As you can see from above class diagram, there are three participants namely, the PersonDaointerface, the implementing class ( PersonDaoImpl ) , and finally a Value Object (VO) / Entity Object (EO) / Data Transfer Object (DTO) — Person that encapsulates the data in an object.

The VO, EO, or DTO are usually used interchangeably in some context but simply there are objects that acts as a mechanism to carry data from/to a database.

The VO / EO / DTO

First of all, here is the Person VO/EO/DTO:

As can be seen, it is simply a very simple Plain Old Java Object (POJO) that encapsulates the data that represent a ‘Person’ entity. It just contains a series of fields that represent the Person attributes with the corresponding getters/setters to retrieve and set the data on the object.

The DAO Interface

Next, let’s define the Java interface that represents this DAO.

Following best object-oriented programming principles we “code to an interface”. i.e. We assume we would have a PersonDao Java interface which defines the list of operations the implementing DAO would implement.

Above shows exactly this example.

DAO is usually in the form of a class per table. As in above example; we assumed we have a Database table called Person in the database. The implementing PersonDaoImpl class would represent that particular Person table.

Note that other forms do exist. It all depends on how you model your internal application objects. For instance, another way to represent a DAO is to have one DAO that acts as an abstraction over a collection of database tables (contextual representation) that represents the equivalent Java application object hierarchy.

You might know this pattern as the Repository pattern.

Also, these other forms are more visible and more popular within the world of Object Relational Mapping (ORM). ORM is a complex subject in itself.

The Implementing Class

Following best Java naming conventions we name the implementing DAO PersonDaoImpl (by adding an impl as suffix to denote that it is an implementing class that ‘implements’ the PersonDao Java interface).

Each method in the DAO would contain code that does what the method exposes.

The implementing class would be like:

In the above code; we first establish a database connection and then have code to send a SQL query or SQL update to the database. This code uses Java’s internal JDBC library to connect to the database. JDBC is Java’s internal library that enables database connectivity to a relational database.

Java standard boilerplate code of using a try catch block mainly for error handling (as we’re connecting to a database which is an external system such that it can fail so we best to handle to errors).