Data access object
<templatestyles src="Module:Hatnote/styles.css"></templatestyles>
In computer software, a data access object (DAO) is an object that provides an abstract interface to some type of database or other persistence mechanism. By mapping application calls to the persistence layer, DAO provide some specific data operations without exposing details of the database. This isolation supports the Single responsibility principle. It separates what data accesses the application needs, in terms of domain-specific objects and data types (the public interface of the DAO), from how these needs can be satisfied with a specific 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 EE applications and with relational databases (accessed via the JDBC API because of its origin in Sun Microsystems' best practice guidelines[1] "Core J2EE Patterns" for that platform).
Contents
Advantages
Lua error in package.lua at line 80: module 'strict' not found. 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.
In the non specific context of the 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. Use of technologies like Java persistence technologies and JDO ensures to some extent that the design pattern is implemented. Technologies like Enterprise JavaBeans come built into application servers and can be used in applications that use a JEE application server. Commercial products like TopLink are available based on Object-relational mapping (ORM). Popular open source ORM products include Doctrine, Hibernate, iBATIS and Apache OpenJPA.
Disadvantages
Potential disadvantages of using DAO include leaky abstraction[citation needed], code duplication,[2] 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. Time consumption is moderate.[citation needed]
Alternatives
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.
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] 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] 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, XAML, JavaScript, Node.js, Atom (standard), (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 compiler-based object-relational mapping (ORM) system for C++
- ORMLite Lightweight Object Relational Mapping (ORM) Framework in Java for JDBC and Android
- Microsoft Entity Framework
See also
References
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ See http://www.ibm.com/developerworks/java/library/j-genericdao/index.html for workarounds