Over the past 18 months, I have joined a team of talented software engineers to build customized, web-based supply chain management applications. Our applications access a wide range of persistent data, including distribution status, supply chain measurement (metrics), inventory, freight invoices, project management data, and user information. We use the JDBC API to connect to our company's different database platforms and use DAO design patterns throughout the application.
Figure 1 shows the relationship between the application and the data source:
Figure 1. Applications and data sources
The use of data Access Objects (DAO) throughout the application allows us to separate the underlying data access logic from the business logic. We built DAO classes that provide Grud (create, read, update, delete) operations for each data source.
In this article, I'll introduce you to the DAO implementation strategy and techniques for building a better DAO class. More specifically, I'll discuss logging, exception handling, and transaction demarcation. You'll learn how to combine those three into your own DAO class. This article assumes that you are familiar with JDBC APIs, SQL, and relational database programming.
We'll start with an overview of DAO design Patterns and data access objects.
DAO Basics
DAO mode is one of the standard Java EE design patterns. This pattern is used by developers to separate the underlying data access operations from the high-level business logic. A typical DAO implementation has the following components:
A DAO factory class
A DAO interface
A concrete class that implements the DAO interface
Data transfer objects (sometimes called value objects)
The specific DAO class contains the logic to access data for a particular data source. In the following section, you will learn the techniques for designing and implementing data Access objects.
Business definition
The important thing to remember about DAO is that they are transactional objects. Each operation performed by DAO-such as creating, updating, or deleting data-is associated with a transaction. Therefore, the concept of a business definition becomes particularly important.
A transaction definition is a way of defining a transaction boundary. The Java EE specification describes two types of transaction-defined models: programmatic (programmatic) and declarative (declarative). The two models are analyzed in table 1:
Table 1. Two types of transaction-defined models
| Declarative transaction definition |
Programmatic definition of transactions |
| The programmer declares the transaction attributes with the EJB deployment descriptor. |
The programmer is responsible for writing the transaction logic. |
| The Run-time environment (the EJB container) uses these properties to automate the management of transactions. |
The application controls transactions through an API. |
We will focus on programming transaction definition.