For faster navigation, this Iframe is preloading the Wikiwand page for Data access object.

Data access object

From Wikipedia, the free encyclopedia

In software, a data access object (DAO) is a pattern that provides an abstract interface to some type of database or other persistence mechanism. By mapping application calls to the persistence layer, the DAO provides some specific data operations without exposing details of the database. This isolation supports the single responsibility principle. It separates what data access the application needs, in terms of domain-specific objects and data types (the public interface of the DAO), from how these needs can be satisfied with a specific DBMS, database schema, etc. (the implementation of the DAO).

Although this design pattern is equally applicable to most programming languages, most types of software with persistence needs, and most types of databases, it is traditionally associated with Java EE applications and with relational databases (accessed via the JDBC API because of its origin in Sun Microsystems' best practice guidelines[1] "Core J2EE Patterns" for that platform).


This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (February 2015) (Learn how and when to remove this template message)

The primary advantage of using data access objects is the relatively simple and rigorous separation between 2 important parts of an application that can but should not know anything of each other, and which can be expected to evolve frequently and independently. Changing business logic can rely on the same DAO interface, while changes to persistence logic do not affect DAO clients as long as the interface remains correctly implemented.

All details of storage are hidden from the rest of the application (see information hiding). Thus, possible changes to the persistence mechanism can be implemented by just modifying one DAO implementation while the rest of the application isn't affected. DAOs act as an intermediary between the application and the database. They move data back and forth between objects and database records. Unit testing the code is facilitated by substituting the DAO with a test double in the test, thereby making the tests independent of the persistence layer.

In the general context of the Java programming language, Data Access Objects as a design concept can be implemented in a number of ways. This can range from a fairly simple interface that separates the data access parts from the application logic, to frameworks and commercial products. DAO coding paradigms can require some skill. Technologies like Java Persistence API and Enterprise JavaBeans come built into application servers and can be used in applications that use a JavaEE application server. Commercial products like TopLink are available based on object-relational mapping (ORM). Popular open source ORM software include Doctrine, Hibernate, iBATIS and JPA implementations such as Apache OpenJPA.


Potential disadvantages of using DAO include leaky abstraction,[citation needed] code duplication, and abstraction inversion. In particular, the abstraction of the DAO as a regular Java object can hide the high cost of each database access, and can also force developers to trigger multiple database queries to retrieve information that could otherwise be returned in a single operation using SQL set operations. If an application requires multiple DAOs, one might find oneself repeating essentially the same create, read, update, and delete code for each DAO. This boiler-plate code may be avoided however, by implementing a generic DAO that handles these common operations.[2]

Hypothetical use scenario

Imagine a situation where you own a successful company that has received contracts to develop an application for 2 different clients. The specifications for the application are nearly identical for the 2 clients. Both clients manage data using SQL databases, but one company uses a proprietary database and the other uses an open source alternative, which implies that your application's persistence layer will need to be implemented in 2 different ways. Further, as new clients arise, additional implementations may be needed. In this case, using the Data Access Object pattern would ensure the right amount of abstraction and encapsulation required to access any of the varying backend databases.

Tools and frameworks

See also


  1. ^ "Core J2EE Patterns - Data Access Objects". Sun Microsystems Inc. 2007-08-02.
  2. ^ See for workarounds
  3. ^ Hodgson, Kyle; Reid, Darren (2015-01-23). ServiceStack 4 Cookbook. Packt Publishing Ltd. p. Chapter 4. ISBN 9781783986576. Retrieved 22 June 2016.
{{bottomLinkPreText}} {{bottomLinkText}}
Data access object
Listen to this article

This browser is not supported by Wikiwand :(
Wikiwand requires a browser with modern capabilities in order to provide you with the best reading experience.
Please download and use one of the following browsers:

This article was just edited, click to reload
This article has been deleted on Wikipedia (Why?)

Back to homepage

Please click Add in the dialog above
Please click Allow in the top-left corner,
then click Install Now in the dialog
Please click Open in the download dialog,
then click Install
Please click the "Downloads" icon in the Safari toolbar, open the first download in the list,
then click Install

Install Wikiwand

Install on Chrome Install on Firefox
Don't forget to rate us

Tell your friends about Wikiwand!

Gmail Facebook Twitter Link

Enjoying Wikiwand?

Tell your friends and spread the love:
Share on Gmail Share on Facebook Share on Twitter Share on Buffer

Our magic isn't perfect

You can help our automatic cover photo selection by reporting an unsuitable photo.

This photo is visually disturbing This photo is not a good choice

Thank you for helping!

Your input will affect cover photo selection, along with input from other users.