|
== Advantages ==
{{unreferenced section|date=February 2015}}
The primary 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.
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.
[[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)|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.
== 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 withusing normal[[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>
== ExampleHypothetical fromuse real worldscenario ==
Imagine a situation where youryou own a successful company gotwhich ahas received contractcontracts to develop an application for two different clients. The specification is roughlyfor the sameapplication despiteare somenearly minoridentical differences.for Thisthe plottwo hasclients. a twistHowever, though. Bothboth clients usemanage data using SQL databases but, one decidedcompany to go foruses a proprietary onedatabase and the other choseuses an open source alternative. This implies that your application will have to have its [[persistence layer]] implemented in at least two different ways. Naturally, manyMany 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 - Datapatterns—Data Access Object. This pattern then ensures the right abstraction and encapsulation of all access to any data source.
== Tools and frameworks ==
| 