- Data Acsess Object
- Forces
- Solution
- Consequences
- Related Patterns
From the book
From the book
Consequences
- Centralizes control with loosely coupled handlers
- Enables transparency
- Provides object-oriented view and encapsulates database schemas
- Enables easier migration
Filters provide a central place for handling processing across multiple requests, as does a controller. Filters are better suited to massaging requests and responses for ultimate handling by a target resource, such as a controller. Additionally, a controller often ties together the management of numerous unrelated common services, such as authentication, logging, encryption, and so on. Filtering allows for much more loosely coupled handlers, which can be combined in various permutations.
Clients can leverage the encapsulation of data sources within the Data Access Objects to gain transparency to the location and implementation of the persistent storage mechanisms.
The clients use transfer objects or data cursor objects (RowSet Wrapper List strategy) to exchange data with the Data Access Objects. Instead of depending on low-level details of database schema implementations, such as ResultSets and RowSets, where the clients must be aware of table structures, column names, and so on, the clients handle data in an object-oriented manner using the transfer objects and data cursors.
A layer of DAOs makes it easier for an application to migrate to a different database implementation. The clients have no knowledge of the underlying data store implementation. Thus, the migration involves changes only to the DAO layer.
- Reduces code complexity in clients
- Organizes all data access code into a separate layer
- Adds extra layer
- Needs class hierarchy design
- Introduces complexity to enable object-oriented design
Since the DAOs encapsulate all the code necessary to interact with the persistent storage, the clients can use the simpler API exposed by the data access layer. This reduces the complexity of the data access client code and improves the maintainability and development productivity.
Data access objects organize the implementation of the data access code in a separate layer. Such a layer isolates the rest of the application from the persistent store and external data sources. Because all data access operations are now delegated to the DAOs, the separate data access layer isolates the rest of the application from the data access implementation. This centralization makes the application easier to maintain and manage.
The DAOs create an additional layer of objects between the data client and the data source that needs to be designed and implemented, to leverage the benefits of this pattern. While this layer might seem to be extra development and run-time overhead, it is typically necessary in order to decouple the data access implementation from the other parts of the application.
When you use a factory strategy, the hierarchy of concrete factories and the hierarchy of concrete products (DAOs) produced by the factories need to be designed and implemented. Consider this additional effort if you think you’ll need this extra flexibility, because it increases the complexity of the design. Use the DAO Factory Method Strategy if that meets your needs, and use DAO Abstract Factory Strategy only if absolutely required.
While the RowSet Wrapper List strategy encapsulates the data access layer dependencies and JDBC APIs, and exposes an object-oriented view of the results data, it introduces considerable complexity in your implementation. You need to decide whether its benefits outweigh the drawbacks of using the JDBC RowSet API in the Cached RowSet strategy, or the performance drawback of using the Transfer Object Collection strategy.