Data access object: Difference between revisions

Revision as of 13:49, 30 September 2006

Latest revision as of 13:16, 2 September 2024

(346 intermediate revisions by more than 100 users not shown)

Line 1:

{{Short description|Abstract interface to a computer database}}

In [[computer software]], a '''Data Access Object''' (DAO) is a [[software component|component]] which provides a common [[Interface (computer science)|interface]] between the [[Application software|application]] and one or more [[data storage device]]s, such as a [[database]] or [[Computer file|file]]. The term is most frequently applied to the Object [[Design pattern (computer science)|design pattern]].

{{About|the software design pattern|the Microsoft library|Jet Data Access Objects}}

In [[software]], a '''data access object''' ('''DAO''') is a pattern that provides an abstract [[Interface (computer science)|interface]] to some type of [[database]] or other [[Persistence (computer science)|persistence mechanism]]. By mapping application calls to the persistence layer, the DAO provides data operations without exposing database details. This isolation supports the [[single responsibility principle]]. It separates the data access the application needs, in terms of ___domain-specific objects and data types (the DAO's public interface), from how these needs can be satisfied with a specific [[Database Management System|DBMS]] (the implementation of the DAO).

== Why use Data Access Objects? ==

Although this [[design pattern]] is applicable to most programming languages, most software with persistence needs, and most databases, it is traditionally associated with [[Java Platform, Enterprise Edition|Java EE]] applications and with [[relational databases]] (accessed via the [[JDBC]] API because of its origin in [[Sun Microsystems]]' best practice guidelines<ref>

Data Access Objects are a Core [[Java 2 Platform, Enterprise Edition|J2EE]] Design Pattern and considered best practice. The advantage of using data access objects is that any [[Business object (computer science)|business object]] (which contains application or operation specific details) does not require direct knowledge of the final destination for the information it manipulates. As a result, if it is necessary to change where or how that data is stored that modification can be made without needing to change the main application.

{{cite web

= | title = WhyCore useJ2EE Patterns - Data Access Objects? ==

| publisher = Sun Microsystems Inc.

| url = http://www.oracle.com/technetwork/java/dataaccessobject-138824.html

| date = 2007-08-02

}}</ref> "Core J2EE Patterns".

This object can be found in the [[Data_access_layer|Data Access layer]] of the [[Multitier_architecture|3-Tier Architecture]].

Data Access Objects can be used in [[Java programming language|Java]] to insulate an application from the underlying Java persistence technology, which could be [[Java Database Connectivity|JDBC]], [[Java Data Objects|JDO]], [[Enterprise JavaBeans|EJB CMP]], [[TopLink]], [[Hibernate (Java)|Hibernate]], [[iBatis]], or any one of a range of technologies. Using Data Access Objects means the underlying technology can be upgraded or swapped without changing other parts of the application.

There are various ways in which this object can be implemented:

== Why not use Data Access Objects? ==

* One DAO for each table.

Flexibility has a price. Adding DAOs to an application hurts not only [[Occam's razor]], more complexity due to using another persistence layer increases the amount of code executed during runtime. Configuration of persistence layers requires in most cases more work than writing a direct persistencifier that accepts [[Data Transfer Object]]s (DTOs).

* One DAO for all the tables for a particular DBMS.

* Where the SELECT query is limited only to its target table and cannot incorporate JOINS, UNIONS, subqueries and Common Table Expressions (CTEs)

* Where the SELECT query can contain anything that the DBMS allows.

== Advantages ==

Especially performance critical applications may not want to use DAOs.

Using data access objects (DAOs) offers a clear advantage: it separates two parts of an application that don't need to know about each other. This separation allows them to evolve independently. If business logic changes, it can rely on a consistent DAO interface. Meanwhile, modifications to persistence logic won't affect DAO clients.<ref>{{Cite web |date=2022-08-03 |title=Data Access Object(DAO) Design Pattern |url=https://www.digitalocean.com/community/tutorials/dao-design-pattern |access-date=2024-07-08 |website=DigitalOcean |language=en-US}}</ref><ref>{{Cite web |date=2017-08-26 |title=Data Access Object(DAO) Design Pattern |url=https://www.geeksforgeeks.org/data-access-object-pattern/#8-advantages-of-the-data-access-object-designdao-pattern |access-date=2024-07-08 |website=GeeksforGeeks |language=en-US}}</ref>

== See also ==

* [[Data Transfer Object]]

* [[Design Patterns]]

* [[Object-relational mapping]]

All details of storage are hidden from the rest of the application (see [[information hiding]]). [[Unit testing]] code is facilitated by substituting a [[test double]] for the DAO in the test, thereby making the tests independent of the persistence layer.

== External links ==

* [http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html Core J2EE Patterns - Data Access Object]

* [http://www.codefutures.com/weblog/andygrove/archives/2005/02/data_access_obj.html Data Access Objects versus Object Relational Mapping]

In the context of the [[Java (programming language)|Java]] programming language, DAO can be implemented in various ways. This can range from a fairly simple interface that separates data access from the application logic, to frameworks and commercial products.

== Tools ==

* http://mdaog.sourceforge.net DAO code generator for [[PostgreSQL]] Databases

* http://www.codefutures.com (Firestorm/DAO) DAO+Web Tier code generator for different databases

* http://titaniclinux.net/daogen DaoGen will generate DAO classes currently only for Java and PHP.

Technologies like [[Java Persistence API]] and [[Enterprise JavaBeans]] come built into application servers and can be used in applications that use a Java EE application server. Commercial products such as [[TopLink]] are available based on [[object–relational mapping]] (ORM). Popular open source ORM software includes [[Doctrine (PHP)|Doctrine]], [[Hibernate (Java)|Hibernate]], [[iBATIS]] and JPA implementations such as [[Apache OpenJPA]].<ref>{{Cite web |date=2017-08-26 |title=Data Access Object(DAO) Design Pattern |url=https://www.geeksforgeeks.org/data-access-object-pattern/ |access-date=2024-01-29 |website=GeeksforGeeks |language=en-US}}</ref>

== Disadvantages ==

{{compu-stub}}

Potential disadvantages of using DAO include [[leaky abstraction]],{{Citation needed|reason=What kind of leak?|date=August 2014}} [[Duplicate code|code duplication]], and [[abstraction inversion]]. In particular, the abstraction of the DAO as a regular Java object can obscure the high cost of each database access. Developers may inadvertently make multiple database queries to retrieve information that could be returned in a single operation. If an application requires multiple DAOs, the same create, read, update, and delete code may have to be written for each DAO.<ref>See http://www.ibm.com/developerworks/java/library/j-genericdao/index.html for workarounds</ref>

[[Category:Software design patterns]]

Note that these disadvantages only appear when you have a separate DAO for each table and the SELECT query is prevented from accessing anything other than the target table.

[[es:Data Access Object]]

[[fr:Objet d'accès aux données]]

== Tools and frameworks ==

[[pl:Data Access Object]]

* [[ODB (C++)|ODB]] compiler-based [[object–relational mapping]] (ORM) system for C++

* ORMLite: Lightweight [[object–relational mapping]] (ORM) framework in Java for JDBC and Android<ref>{{cite book|last1=Hodgson|first1=Kyle|last2=Reid|first2=Darren|title=ServiceStack 4 Cookbook|publisher=Packt Publishing Ltd|isbn=9781783986576|page=Chapter 4|url=https://books.google.com/books?id=x9hpBgAAQBAJ&q=%22ORMLite%22&pg=PA129|access-date=22 June 2016|language=en|date=2015-01-23}}</ref>

* [[Entity Framework|Microsoft Entity Framework]]

* DBIx::Class [[object–relational mapping]] (ORM) module for [[Perl]]

* TuxORM: Simple [[object–relational mapping]] (ORM) library in Java for JDBC

* [[Persist (Java tool)]] Java-based [[object–relational mapping]] and data access object tool

== See also ==

* [[Create, read, update and delete]] (CRUD)

* [[Data Transferaccess Objectlayer]]

* [[Service Data Objects]]

* [[Object-relationalObject–relational mapping]]

== References ==

{{Reflist}}

* [[{{Design Patterns]] Patterns}}

[[Category:Architectural pattern (computer science)]]

[[Category:Software design patterns]]