Shulou(Shulou.com)06/02 Report--

This article introduces how to analyze the session and data access objects in J2EE architecture design. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

The class diagram in figure 1 briefly describes the design pattern of the session surface, and figure 2 shows the sequential representation of the session surface, that is, the participating components and their interactions.

Fig. 1 session surface class diagram

Fig. 2 sequence diagram of session surface

Here we give a brief introduction to the various components of figure 7:

(1) customer (Client). This means that the customer in the conversation, that is, the client application that needs to access the relevant enterprise services, can also be another session bean at the same or different levels.

(2) session (Session Facade). Session plane is usually implemented by session bean, which manages the relationship between multiple enterprise objects and provides a high-level abstract interface to users.

(3) Business object (Business Object) A business object is an object that can use many different designs, such as session bean, entity bean, and data access objects. In figure 1, the business object is responsible for providing data and services, while the session needs to interact with multiple business object instances to obtain the corresponding services.

The session is actually a control object of the business layer, which is responsible for controlling the interaction between users and enterprise data and enterprise service objects; in a complex application system, there may even be multiple sessions as an intermediary between the user and the object module.

Here are two common ways to implement a session.

(1) stateless conversation surface

When implementing a session, you should first decide whether to use a stateful or stateless session bean, which mainly depends on the business process modeled by the session; if a business process needs only one method call to implement its service, then it can be implemented using a stateless session bean.

(2) the state of the conversation.

When a business process requires multiple method calls to implement its services, the developer uses a stateful session bean to implement the process, because the state information for each method call must be saved in the session bean.

By adopting the design pattern of session surface in the application system, the following benefits will be obtained in the system:

① provides users with a simple interface and hides all complex interactions with system components.

② reduces the number of enterprise objects exposed to users, thereby reducing their dependencies

③ hides the interaction process and dependencies between system components from users, which makes the system easier to manage and provides considerable flexibility; it provides a set of unified user access mechanism to facilitate the management of users' requests and access to system services.

6. Data access object

The data access object (data access object,DAO) pattern abstracts the data access logic into special resources, that is, isolates the interfaces of system resources from its underlying access mechanism; by packaging the calls to data access, data access objects can promote data access to different database types and patterns.

The background of this pattern is that the logic of data access largely depends on the format of data storage, such as relational database, object-oriented database, disk file and so on.

At present, most J2EE applications need to use persistent data to some extent, and the methods of implementing persistent data vary from application to application, and there are significant differences in application program interfaces (API) for accessing data in different storage formats. Sometimes, applications also access data stored on different operating platforms, which complicates the problem. Often, applications use shared distributed components, such as entity bean, to express persistent data. Applications can use bean-managed persistence entity bean, and plant human data access logic in entity bean, or use container-managed persistence entity bean, so that the container manages all transaction and persistence details; and if the application's requirements for data access are very simple, it can also use session bean or Servlet to access persistent storage directly to read and modify data.

Some applications can use JDBC API to access data in relational databases. JDBC is responsible for general persistent data access and management. In J2EE applications, SQL statements can be embedded in JDBC to access relational databases. Of course, the morphology and syntax of SQL statements vary depending on the type of database. It should be noted that when the data storage format is different, the difference of data access logic is more obvious, such as relational database, object-oriented database and disk file, each has its own data access logic. this results in a dependency between program code and data access code. When program components, such as entity bean, session bean or servlet, JSP, etc., need to access the data source, they use the correct application program interface to get the connection and manage the data source, but this also creates dependencies between these components and the physical implementation of the data source, which makes it difficult for applications to migrate from one data storage entity to another. When the physical implementation of the data source changes, the application must change accordingly.

Based on the problems discussed above, developers began to adopt the method of data access objects. Data access objects are actually objects that contain all data access logic and manage connections to data sources. Data access objects implement different access mechanisms according to different data sources. The data sources mentioned here can be persistent storage media, such as relational databases, or external services, such as B2B data exchange. Not only the user, but also other components in the application system can also use the data access interface provided by the data access object, which completely separates the physical implementation details of the data source from its user. and when the underlying data source changes, the interface provided by the data access object to the user will not change. This method enables the application system to adapt to a variety of data storage media when using data access objects. in short, the data access object is the adapter between the system component and the data source.

The class diagram in figure 3 shows the participating objects and the invocation relationship between the data access object design pattern, and figure 4 is a sequence diagram of this design pattern.

Fig. 3 data access object class diagram

Fig. 4 sequence diagram of data access objects

The components in the sequence diagram of figure 9 are explained as follows:

(1) Business object (Business Object) The user who represents the data, which requires access to the data. A business object can be implemented by session bean, entity bean, or other Java programs.

(2) data access object (Data Access Object) The data access object is the theme of this pattern, which provides the underlying data access object and provides it to the business object so that the latter can access the data source transparently; at the same time, the business object also transfers the loading and storage operations of the data to the data access object processing.

(3) data source (Data source). This refers to the physical implementation of a data source, which can be a database, including a relational database, an object-oriented database, or a file system.

(4) transfer object (Transfer Object). The transmission object here refers to the data carrier. Data access objects can use transfer objects to return data to users, and data access objects can also get transfer objects from users to update data in the data source.

Here are several ways to implement the data access object design pattern.

(1) automatic generation of data access object code

Since each business object corresponds to a data access object, developers can establish a relationship between the business object, the data access object, and the underlying implementation; once this relationship is established, developers can write special code generation tools for all data access objects.

The information that generates data access objects is usually stored in a developer-defined description file, and if the requirements for data access objects are too complex, developers can consider using third-party tools to provide object-to-relational mapping for relational databases. These tools are usually GUI programs that can be used to map business objects to persistent storage objects and define intermediate data access objects. When the mapping is completed, these tools can automatically generate code and provide some corresponding functions, such as caching results, caching queries, integrating with application servers, integrating with third-party products, and so on.

(2) data access object Agent (Factory for Data Access Objects)

When the underlying data store will not be easily changed, the developer can take this approach to implement the corresponding data access object. Figure 5 is the class diagram of this method.

Figure 5 using the DAO agent class diagram

When the underlying data storage may change, developers can use abstract proxy methods to implement data access objects; abstract proxy methods create some virtual data access object proxies and various types of actual data access object proxies, each object corresponds to an implementation of a persistent storage medium, once the component has these proxies, it can be used to create data access objects that need to be used.

Figure 6 shows a class diagram for this situation. This class diagram represents a basic data access object agent, which is an abstract class inherited by other actual data access object agents to support specific data access functions. Users can get an actual data access object and use it to create needed data access objects and access related data. each actual data access object is responsible for establishing a connection to the data source. and get and manage the supported business data.

Figure 6 Abstract Agent using DAO

Figure 7 below is a sequence diagram in this case.

Figure 7 Abstract Agent using DAO sequence Diagram

The advantages of this design pattern are:

Good transparency. Business objects can access data without knowing the details of the data source implementation. Because all data access details are hidden by the data access object, this access process is transparent.

Good portability. By adding data access objects to the application system, the former can be easily transplanted to another database implementation. The business object is isolated from the data implementation, so only some changes can be made to the data access object during the migration process.

Reduce the code complexity of business objects. Because the data access object can manage all the complex details of data access, this simplifies the code for business modules and other data customers. At the same time, it also improves the overall readability and development rate of the application system.

Centralize all data access. Because all the data access operations are handed over to the data access object, the rest of the application system is isolated from the data access implementation, and all related operations are centrally handled with the data access object. this also makes related operations easier to maintain and manage.

The drawbacks of this design pattern are:

Container-managed persistence cannot be exploited. If the EJB container takes a container-managed approach, the container is responsible for all management of persistent data stores. In this way, the application system does not need to implement the data access object, because the application service will provide this function transparently.

Additional layers have been added. The data access object adds a layer between the data user and the data source, which adds some additional design and implementation burden. Of course, we think it's worth it.

In short, when developers choose different patterns, it should be noted that certain patterns correspond to certain application levels. For example, the patterns related to view and display are applied at the Web layer. Some of the patterns related to business logic control are related to the EJB hierarchy. Other patterns for reading data and dispatching operations apply to different levels.

On how to analyze the J2EE architecture design of the session and data access objects to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.