Data access object: Difference between revisions

Revision as of 10:44, 30 June 2023

Latest revision as of 13:16, 2 September 2024

(6 intermediate revisions by 5 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}}

Line 10 ⟶ 11:

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

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 primary advantage of usingUsing data access objects is(DAOs) theoffers rigorousa separationclear advantage: it betweenseparates two parts of an application that have nodon't need to know anything about each other,. andThis whichseparation thereforeallows canthem evolveto frequently andevolve independently. ChangingIf business logic changes, it can rely on a constantconsistent DAO interface. Meanwhile, while changesmodifications to persistence logic do notwon'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.

Line 19 ⟶ 28:

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-relationalobject–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 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>

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.

== 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&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-relationalobject–relational mapping]] (ORM) module for [[Perl]]

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

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

== See also ==

Line 36 ⟶ 47:

* [[Data access layer]]

* [[Service Data Objects]]

* [[Object-relationalObject–relational mapping]]

== References ==

{{Reflist}}

|url=https://www.oracle.com/java/technologies/data-access-object.html

{{Design Patterns Patterns}}