The Data Access Object Pattern (Structural – Not a GoF Pattern) ©SoftMoore ConsultingSlide 1

Motivation Most real-world applications need to use persistent data. Mechanisms for persisting data vary greatly –Text Files (e.g., CSVs) – XML Files –Relational Databases– Object-Oriented Databases –NoSQL Databases – LDAP Repositories –Web Services– Proprietary Systems Even when using a relational database, the actual syntax and format of SQL statements can vary from one RDBMS vendor to another. How do we maintain flexibility so that the underlying persistence mechanism can be changed with minimal impact on the rest of the application? ©SoftMoore ConsultingSlide 2

Data Access Object – Basic Idea Abstract and encapsulate the details of persistence into a data access layer by separating business/application objects from the data access objects. Data access objects are the only objects that have knowledge of and communicate with the underlying persistence mechanism. They encapsulate all persistence-related functions. Changes to the persistence mechanism require changes to the DAO layer only, and not to the application objects. For this pattern to be effective, it is important that no (or at least minimal) details of the persistence mechanism “leak” out of the DAO layer. ©SoftMoore ConsultingSlide 3

Data Access Object Pattern Intent: Separate application logic from the logic used to access the underlying persistence mechanism, thereby allowing the persistence mechanism to change without impacting the rest of the application Applicability: Use the Data Access Object Pattern when any of the following apply: –An application uses a lot of persistent data. –The persistence mechanisms are likely to change during the lifetime of an application. –An application needs to support different vendor products for persistence. –Portability of an application is a key design consideration. Slide 4©SoftMoore Consulting

Data Access Object Pattern (continued) ©SoftMoore ConsultingSlide 5 Structure BusinessObjectDataAccessObject Data Source

Data Access Object Pattern (continued) Participants BusinessObject –represents an object used by an application that requires persistence (e.g., Employee, Customer, Order, etc.) –contains business/application logic, but does not know how to store itself in a persistence mechanism. DataAccessObject –abstracts and encapsulates access to the persistence mechanism for the business object. –all access to the underlying persistence mechanism goes through the DataAccessObject. –provides persistence CRUD (create, read, update, delete) operations for the BusinessObject. ©SoftMoore ConsultingSlide 6

Data Access Object Pattern (continued) Participants (continued) Data Source –represents the persistence mechanism (e.g., RDBMS, text file, LDAP repository, etc.) Other possible participants include –TransferObject serves as a data carrier returns data to the BusinessObject –A DAOFactory for creating/returning DAO objects can use AbstractFactory pattern for different persistence mechanisms (e.g., different databases) ©SoftMoore ConsultingSlide 7

Data Access Object Pattern (continued) Collaborations BusinessObject uses the DataAccessObject for all access to the underlying persistence mechanism. DataAccessObject communicates directly with DataSource to persist the BusinessObject. ©SoftMoore ConsultingSlide 8

Data Access Object Pattern (continued) Consequences: The Data Access Objects pattern Localizes access to the persistence mechanism. Since all access to the persistence mechanism is encapsulated in the DataAccessObject, ripple effects from possible changes to the persistence mechanism are minimized. In addition, changes to add additional functionality or improve performance are straightforward. Simplifies replacement of the persistence mechanism. Migration to a different database or persistence mechanism involves changes only to the DAO layer. ©SoftMoore ConsultingSlide 9

Data Access Object Pattern (continued) Consequences (continued) Reduces complexity of business objects. Logic to manage access to the data source is moved from business objects to data access objects. ©SoftMoore ConsultingSlide 10

Data Access Objects Pattern (continued) Implementation Using a DAOFactory. Using an Abstract Factory to create specific DAO objects can improve portability and flexibility, especially when it is known in advance that an application needs to support different vendor products for persistence. Naming Conventions. DataAccessObjects often use the same name as the business/application object with a “ DAO ” suffix; e.g., Customer and CustomerDAO. ©SoftMoore ConsultingSlide 11

DAO Example (Example of a Business Object) public class Student { private String id; private String lastName; private String firstName; private Date dateOfBirth; private String sex; private String ethnicity; private String major;... // constructors, get/set methods, etc.... // toString(), equals(), hashCode(), etc. } ©SoftMoore ConsultingSlide 12

DAO Example (Abstract Superclass for all Data Access Objects) public abstract class DAO {... // methods useful for all data access objects public Log getLog() {... } /** * Executes an insert, update, or delete query. the row count for the query */ public int executeUpdate(String query) {... } public void close(Statement stmt, Connection conn) {... } } ©SoftMoore ConsultingSlide 13

DAO Example (Example of a Data Access Object) public class StudentDAO extends DAO {... // constructor and other methods public int insert(List stucents) {... } public int update(List students) {... } public int remove(List ids) {... } public Student get(String id) {... } ©SoftMoore ConsultingSlide 14 (continued on next slide)

DAO Example (Example of a Data Access Object − continued) public List getBasedOnLastName (String lastNamePrefix) {... } public List getAllMajors(String major) {... } } ©SoftMoore ConsultingSlide 15

Automated Tools for DAO Objects FireStorm/DAO by CodeFutures DaoGen by TitanicLinux.Net DAO4J DB Visual ARCHITECT by Visual Paradigm ©SoftMoore ConsultingSlide 16

Related Patterns Abstract Factory can be used to create data access objects for different business objects. Concrete factories can be implemented for different databases/persistence mechanisms. ©SoftMoore ConsultingSlide 17

References Data access object pattern (Wikipedia) Core J2EE Patterns – Data Access Object Write once, persist anywhere: Implement a Data Access Object pattern framework (James Carman, JavaWorld) Database Interaction with DAO and DTO Design Patterns (by Sandeep Bhandari, JavaLobby) Data Access Object (Best Practice Software Engineering) ©SoftMoore ConsultingSlide 18