Home > Articles > Software Development & Management

  • Print
  • + Share This
From the book Consequences

Consequences

  • Centralizes control with loosely coupled handlers
  • 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.

  • Enables transparency
  • 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.

  • Provides object-oriented view and encapsulates database schemas
  • 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.

  • Enables easier migration
  • 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
  • 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.

  • Organizes all data access code into a separate layer
  • 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.

  • Adds extra layer
  • 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.

  • Needs class hierarchy design
  • 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.

  • Introduces complexity to enable object-oriented design
  • 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.

  • + Share This
  • 🔖 Save To Your Account