Content deleted Content added
Adding/improving reference(s), Grammar edit |
rm whitespace |
||
| (3 intermediate revisions by 2 users not shown) | |||
Line 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 ==
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 24 ⟶ 32:
== 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 ==
Line 41 ⟶ 51:
== References ==
{{Reflist}}
{{Design Patterns Patterns}}
| |||