Content deleted Content added
Line 5:
Data Access Objects are a Core [[Java 2 Platform, Enterprise Edition|J2EE]] Design Pattern and considered best practice. The advantage of using data access objects is that any [[Business object (computer science)|business object]] (which contains application or operation specific details) does not require direct knowledge of the final destination for the information it manipulates. As a result, if it is necessary to change where or how that data is stored that modification can be made without needing to change the main application.
Data Access Objects can be used in [[Java programming language|Java]] to insulate an application from the underlying Java persistence technology, which could be [[Java Database Connectivity|JDBC]], [[Java Data Objects|JDO]], [[Enterprise JavaBeans|EJB CMP]], TopLink, [[Hibernate (Java)|Hibernate]], iBatis, or any one of a range of technologies. Using Data Access Objects means the underlying technology can be upgraded or swapped without changing other parts of the application.
== Why not use Data Access Objects? ==
Flexibility has a price. Adding DAOs to an application hurts not only Ocam's razor. More complexity due to using another persistence layer increases the amount of code executed during runtime. Configuration of persistence layers requires in most cases more work than writing a direct persistencifier that accepts DTOs.
Especially performance critical applications may not want to use DAOs.
== See also ==
| |||