Accessing Persistent Data in a Relational Database

Introduction

Most applications will need to access persistent data at some point, which may reside in relational databases, flat files, mainframe systems, LDAP repositories, or be provided by services through external systems. When business components need to access a data source, they need to use the appropriate mechanism to achieve connectivity and manipulate the stored data. Mechanisms to access these different types of persistent storage differ greatly, often incorporating proprietary APIs; access mechanisms for different data sources rarely have much in common. For example, accessing a relational database in Java requires using the JDBC API – this API cannot be used in many circumstances other than accessing a relational database.

Usage of these different access mechanisms can potentially create a direct dependency between business logic and data access code. If a business module relies on the internal workings or implementation of a data access module, or if the business module directly includes some aspects of the connectivity and data access code, a tight coupling is created between the business and data logic, directly affecting the portability of each.

The following diagram illustrates the structure of a typical application which accesses persistent data stored in a relational database. The data logic and JDBC API are embedded to some degree within the business logic, tightly coupling the two layers together.

Figure 1 - Typical Application Structure

Tight coupling between modules will produce a number of difficulties and issues:

• Changes in one module will potentially force a ripple of changes in the other module

• Modules will be more difficult to understand in isolation

• Modules will be difficult to r...

... middle of paper ...

...object design from the relational database implementation.

• Reduces code complexity in business modules

Since the DAOs encapsulate all of the code necessary to interact with the persistent storage, the business modules 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 of the business layer.

• Organizes all data access code into a separate layer

The DAOs organize the implementation of the data access code into a separate layer, which 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.