Data access object: Difference between revisions

Revision as of 20:06, 4 May 2018

Latest revision as of 13:16, 2 September 2024

(32 intermediate revisions by 29 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 [[single 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 most programming languages, most types of software with persistence needs, and 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]].

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

* One DAO for each table.

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

{{unreferenced section|date=February 2015}}

The advantage of using data access objects is the relatively simple and rigorous separation between two 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 non-dependent on the persistence layer.

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>

In the non specific context of the [[Java (programming language)|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 (PHP)|Doctrine]], [[Hibernate (Java)|Hibernate]], [[iBATIS]] and JPA implementations such as [[Apache OpenJPA]].

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

In the non specific context of the [[Java (programming language)|Java]] programming language, Data Access Objects as a design conceptDAO can be implemented in a number ofvarious 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 JavaEEJava EE application server. Commercial products likesuch as [[TopLink]] are available based on [[object-relationalobject–relational mapping]] (ORM). Popular open source ORM software includeincludes [[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>

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.

== Example from real world ==

Imagine a situation where your successful company got a contract to develop an application for two different clients. The specification is roughly the same despite some minor differences. This plot has a twist though. Both clients use SQL databases but one decided to go for a proprietary one and the other chose an open source alternative. This implies that your application will have to have persistence layer implemented in at least two different ways. Naturally, many more implementations may be needed as new clients arise. Your best choice to solve this portability problem in Java EE would be using one of core J2EE patterns - Data Access Object. This pattern then ensures the right abstraction and encapsulation of all access to any data source.

== Tools and frameworks ==

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

* ORMLite: Lightweight [[object-relationalobject–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&pg=PA129&dq=%22ORMLite%22#v=onepage&q=%22ORMLite%22&fpg=falsePA129|accessdateaccess-date=22 June 2016|language=en|date=2015-01-23}}</ref>

* [[Entity Framework|Microsoft Entity Framework]]

* [http://www.dbix-class.org/about.html DBIx::Class] [[object-relationalobject–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 38 ⟶ 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))]

* [https://kore.fi.muni.cz/wiki/index.php?title=Data_Access_Object_(English) Data Access Object (English)]

{{Design Patterns Patterns}}

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

[[Category:Software design patterns]]