Data access object: Difference between revisions

Content deleted Content added
m Add reference to the DAO being part of the 3-Tier Architecture.
rm whitespace
 
(2 intermediate revisions by 2 users not shown)
Line 12:
}}</ref> "Core J2EE Patterns".
 
This object can be found in the [[Multitier_architecture#Common_layersData_access_layer|Data Access layer]] of the [[Multitier_architecture|3-Tier Architecture]].
 
There are various ways in which this object can be implemented:
Line 19:
* 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}}
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>
 
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 52 ⟶ 51:
== References ==
{{Reflist}}
 
|url=https://www.oracle.com/java/technologies/data-access-object.html
{{Design Patterns Patterns}}