Data access object: Difference between revisions

Revision as of 23:44, 22 November 2022

Revision as of 05:00, 28 November 2022

Line 1:

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

In [[Software|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 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

Line 9:

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

| date = 2007-08-02

}}</ref> "Core J2EE Patterns" for that platform).

== Advantages ==

{{unreferenced section|date=February 2015}}

The primary advantage of using data access objects is the relatively simple and rigorous separation between 2 importanttwo parts of an application that canhave butno shouldneed notto know anything ofabout each other, and which therefore can be expected to evolve frequently and independently. Changing business logic can rely on thea sameconstant 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]] for the DAO in the test, thereby making the tests independent of the persistence layer.

In the general 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 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]].

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-relational mapping]] (ORM). Popular open source ORM software includeincludes [[Doctrine (PHP)|Doctrine]], [[Hibernate (Java)|Hibernate]], [[iBATIS]] and JPA implementations such as [[Apache OpenJPA]].

== 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 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 [[Set operations (SQL)|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>

== Disadvantages ==

== Hypothetical use scenario ==

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 using [[Set operations (SQL)|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>

{{inappropriate person|section|you|date=November 2022}}

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