Data access object: Difference between revisions

Revision as of 07:57, 15 February 2017

Latest revision as of 13:16, 2 September 2024

(48 intermediate revisions by 40 users not shown)

Line 1:

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

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

In [[computer software]], a '''data access object''' ('''DAO''') is ana [[Object (computer science)|object]]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 some specific data operations without exposing database details of the database. This isolation supports the [[Singlesingle responsibility principle]]. It separates whatthe data access the application needs, in terms of ___domain-specific objects and data types (the DAO's public interface of the DAO), from how these needs can be satisfied with a specific [[Database Management System|DBMS]], database schema, etc. (the implementation of the DAO).

Although this [[design pattern]] is equally applicable to the following: (1- most programming languages; 2-, most types of software with persistence needs;, and 3- most types of 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>

{{cite web

| title = Core J2EE 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" for that platform).

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

open source ORM products include [[Doctrine (PHP)|Doctrine]], [[Hibernate (Java)|Hibernate]], [[iBATIS]] and JPA implementations such as [[Apache OpenJPA]].

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

== Disadvantages ==

* One DAO for each table.

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 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 with normal 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.<ref>See http://www.ibm.com/developerworks/java/library/j-genericdao/index.html for workarounds</ref> Time consumption is moderate.{{Citation needed|date=December 2014}}

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

<!-- complete hogwash and speculation; original research with no sourcing whatsoever; title is "alternatives" in plural, while only one resemblance of alternative is presented. Commented out for now, maybe revive after there are several alternatives to DAOs

* 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.

== AlternativesAdvantages ==

DAO is a product of deep legacy thinking in which data objects in a computer's memory are '''translated''' into the [[third normal form]] data model of a relational database. This represents a significant overhead for development and maintenance and is usually chosen because of the desire to benefit from the productivity which can be derived from the use of [[SQL]].

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>

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.

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.

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 ==

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 hideobscure the high cost of each database access,. andDevelopers canmay also force developers toinadvertently triggermake multiple database queries to retrieve information that could otherwise be returned in a single operation with normal SQL set operations. If an application requires multiple DAOs, one might find oneself repeating essentially the same create, read, update, and delete code formay eachhave DAO. This boiler-plate code mayto be avoidedwritten however,for by implementing a genericeach DAO that handles these common operations.<ref>See http://www.ibm.com/developerworks/java/library/j-genericdao/index.html for workarounds</ref> Time consumption is moderate.{{Citation needed|date=December 2014}}

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.

[[XML]] is an alternative foundation on which to design and build a Persistence and Integration Strategy (which also includes Presentation) for modern software.{{Citation needed|date=December 2014}} When used with the objective of having minimal data format translation, whole systems can be built with XML that don't require the inherent data format translation of the DAO model.{{Citation needed|date=December 2014}} XML is self describing and self altering from the following points of view: 1) its schema can be defined in XML with .[[XSD]] files; and 2) it can be transformed using XML in the form of .[[XSLT]] and .[[CSS]] files. When combined with [[XQuery]] (replacing SQL), [[jQuery]], [[HTML5]], [[Extensible Application Markup Language|XAML]], [[JavaScript]], [[Node.js]], [[Atom (standard)]], ([[Representational state transfer|REST]]), [[JSON]], [[RAML (software)]] and databases like [[eXist]] and [[CouchDB]], software applications can be built with the "XML everywhere" model, which is agile, brief and powerful. In this model, the application design, work flow and configuration is also in XML, and each of these is used to assemble the Atom service calls into an XML application which talks to human beings, databases and other computer services with the same basic paradigm: XML. This approach also provides an advantage when targeting mobile apps by using an HTML5 Compiler. -->

== Tools and frameworks ==

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

* ORMLite: Lightweight Object Relational[[object–relational Mappingmapping]] (ORM) Frameworkframework 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&pg=PA129&dq=%22ORMLite%22&hl=en&sa=X&ved=0ahUKEwjZmtmDnLzNAhUY2WMKHYbRClgQ6AEIJjAB#v=onepage&q=%22ORMLite%22&fpg=falsePA129|accessdateaccess-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 ==

Line 32 ⟶ 47:

* [[Data access layer]]

* [[Service Data Objects]]

* [[Object–relational mapping]]

== References ==

{{Reflist}}

== External links ==

* [http://tutorials.jenkov.com/java-persistence/dao-design-pattern.html ''Java Persistence'' - ''The DAO Design Pattern'']

* [http://www.odi.ch/prog/design/php/guide.php PHP best practices (Use Data Access Objects (DAO))]

{{Design Patterns Patterns}}

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

[[Category:Software design patterns]]