Data Access object pattern in Java schema design

A lot of Java EE applications need to use persistent data (databases, files, etc.). Different programs, persistent storage are different, and the APIs used to access these different persistence storage mechanisms are quite distinct. If your application wants to migrate between different persistent storage tiers, the code that accesses a particular persistent storage tier will face rewriting.

How to solve this problem? and see "DAO mode"

Data Access Objects (Acess object) mode

I. Environment

Data access is different depending on the data source. Depending on the type of storage (relational database, object-oriented database, file, and so on) and vendor implementations, persistent storage, such as databases, is significantly different.

Two. The question

Many really Java EE applications need to use persistent data to some extent. For many applications, persistent storage is implemented using a different mechanism, and the APIs used to access these different persistence storage mechanisms are very different.

For example, the application uses a distributed component of entity beans (where BMP-bean,cmp beans have significantly reduced coupling to the RDBMS) to represent persistent data, or use the JDBC API to access data residing in a relational database management system (RDBMS). The inclusion of connectivity and data access code in these components introduces a tight coupling between these components and the data source implementation. This type of code dependency in a component makes it cumbersome and difficult for an application to migrate from one source of data to another type of data source. When the data source changes, the component also needs to be changed so that it can handle the new type of data source.

(for example, our Uptel system uses the JDBC API to connect and data access to Oracle databases, which are scattered in the system with SQL statements, when we need to migrate Uptel to other RDBMS, such as once migrating to Informix, You are faced with modules that override database connections and access data. )

Three. Force

1. Components such as bean-managed entity beans, session beans, and servlet often need to retrieve data from persistent storage data sources, as well as to perform operations such as data storage.

2. Depending on the product vendor, the persistence storage API is also very different, and the APIs and their capabilities vary according to the type of storage, which has the following drawbacks: The APIs for accessing these stand-alone systems are very different.

3. Components need to be transparent to actual persistent storage or data source implementations to facilitate easier porting to different vendor products, different storage types, and different data source types.

Four. The solution

Use the data Access object (DAO) pattern to abstract and encapsulate all access to the data source. DAO manages the connection to the data source to retrieve and store the data.

DAO implements the access mechanism used to manipulate the data source. Data sources can be rdbms,ldap,file and so on. A business component that relies on DAO provides a simpler interface for its clients to use DAO. The DAO completely hides the data source implementation details from the client. Because the interface provided by DAO to clients does not change when low-level data sources are implemented, all of this mode allows DAO to adjust to different storage modes without affecting its clients or business components. It is important that DAO acts as an adapter between components and data sources.

(according to this theory, if our Uptel system uses DAO mode, we can seamlessly migrate from Oracle to any RDBMS.) Dreams are always perfect, and see how DAO patterns are implemented.

1. Structure, figure 1 is a class diagram that represents the various relationships in the DAO pattern.

The relevant pictures of this topic are as follows: