Core J2EE Patterns: Data Access Object Pattern
- Data Acsess Object
- Forces
- Solution
- Consequences
- Related Patterns
From the book
From the book
Data Acsess Object
Problem
You want to encapsulate data access and manipulation in a separate layer.
Many real-world J2EE applications implement persistent objects as Business Object (374), which use POJOs or entity beans. An application with simpler requirements might forego using business objects and instead use Session Façdes (341), Application Services (357), or other helper objects that directly access and manipulate data in the persistent storage. Such business objects and application components require access to business data in a persistent store.
Most enterprise applications typically use relational database management systems (RDBMS) as the persistent store. However, enterprise data can reside in other types of repositories, such as mainframe or legacy systems, Lightweight Directory Access Protocol (LDAP) repositories, object-oriented databases (OODB), flat files, and so on. Another example of persistent storage is where data is provided by services in external systems, such as business-to-business (B2B) integration systems, credit card bureau services, and so on.
Access mechanisms, supported APIs, and features vary among such persistent stores. Even within a single API, the underlying implementations might provide proprietary extensions in addition to standard features.
Mingling persistence logic with application logic creates a direct dependency between the application and the persistence storage implementation. Such code dependencies in components make it difficult and tedious to migrate the application from one type of data source to another. When the data source changes, the components must be modified to handle the new type of data source.