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

Editor to share with you the J2EE architecture design of value objects, transfer objects, intercept filter example analysis, I believe that most people do not understand, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

7. Value object or transfer object

The value object (value object) pattern facilitates the exchange of data by reducing messages for distributed communication, which usually refers to communication between the Web layer and the EJB layer. In a remote call, a single-valued object can be used to fetch a series of related data and provide it to the customer.

The emergence of this design pattern is based on the fact that customers need to exchange a large amount of data with ejb. Specifically, in the J2EE platform, application systems usually implement server-side program components as session bean and entity bean, and some of the methods of these components need to return data to customers In this case, usually a user will repeatedly call the relevant method many times until it gets the relevant information, and it should be noted that in most cases the purpose of these method calls is to obtain a single information, such as user name or user address.

Obviously, on the J2EE platform, this kind of call is basically from remote. In other words, the user calls the corresponding method multiple times will put a great burden on the Web, even if the user and the EJB container load the same JVM, OS, and running EJB programs on the computer, because the method call is considered to be a remote task by default, this problem still exists.

Due to the problems mentioned above, the performance of the related application will be greatly degraded when the number of remote method calls increases, so it is very inefficient to obtain a single information by using multiple method calls; in this case, J2EE researchers suggest using a transfer object to contain all program data, that is, each method call can send and receive the transfer object When a user makes a request for program data to EJB, EJB creates the transfer object, assigns relevant values to its fields, and passes the entire object to the user.

When EJB uses a transfer object, the user can get the entire object with only one method call, rather than using multiple method calls to get the value of each field in the object; because the transfer object is passed to the user through value transfer, all calls or values to the transfer object are local calls, not remote method calls. It is important to note, however, that the transport object must have an access method corresponding to each property, or make all properties public.

Class figure 13 represents the architecture of the transport object pattern.

Fig. 13 transfer object class diagram

In figure 13, the transport object is first created in EJB and then returned to the remote customer; of course, the transport object can also incorporate other design patterns as needed.

Figure 14 shows the participating modules in the transport object mode and their interaction.

Fig. 14 sequence diagram of transmission objects

Let's describe the participating modules of the transfer object pattern:

(1) customer (Client). The customer represents the consumer of the services provided by EJB, usually the application running on the user terminal.

(2) Business object. A business object represents a role implemented in a pattern by a session bean, entity bean, or data access object (Data Access Object). Business objects are usually responsible for creating transport objects and transmitting them to the relevant users upon request; business objects can also take data in the format of a transfer object from the user and apply the data to perform some updates.

(3) transfer object. The transfer object is a serializable Java object. In the class of this object, there is usually a constructor that contains all the fields to create the transport object.

The member variables in this transport object are basically defined as public, so there is no need to provide them with related access methods. Of course, if there is a need for security, the relevant member variables can also be set to protected or private, and given their respective access methods. Thus it can be seen that the design of the transmission object changes with the different needs of the application system, whether to set the member variables in the object to public, or to provide certain access methods, will be a very important design problem.

Usually, when implementing this pattern, the updatable transfer object strategy and multi-transfer object strategy are adopted at most. In the updatable transport object strategy, the transport object can not only obtain the relevant information and data from the business object serving the user, but also get the changes that the user needs to make to the data from the business object. Figure 15 shows the relationship between business objects and transport objects in the form of a class diagram.

Figure 15 updatable transfer object class diagram

The business object creates the transport object. By accessing the business object, users not only get the required information, but also make certain modifications to the relevant data. In order to enable users to modify the values of each domain of the business object, the object must provide a certain variable value method. For the sake of Web burden, the method provided by the business object takes the transfer object as a parameter. Accordingly, these methods can call the methods provided by the transfer object to set the values of each member variable of the transfer object. At the same time, in the method of transferring the object, we can also implant the logic of data verification and integrity check, so that when the user gets the transfer object from the method of the business object, you can directly call the member method of the transfer object for local data access, of course, this local data access will not affect the business object.

When the user calls the variable value method of the business object, the method serializes the client's transport object and sends it to the business object; the business object receives the updated transport object and writes the updates back to its own copy of the object. It should be noted that the writeback mentioned above only involves the updated variables, not the writeback of all variables, so we need to set another variable in the transfer object to specify which member variables have been updated by the user. this makes the design of this pattern relatively complex, and developers need to consider synchronization and version control.

Figure 16 shows the sequence diagram of this update process.

Figure 16 updatable sequence diagram of transmission objects

The method of multiple transfer objects means that a single business object can create multiple different transmission objects according to the user's request. That is, a business object maintains an one-to-many relationship with the transport object it creates. Class figure 17 shows the participating modules of this implementation method and the invocation relationship between them.

Fig. 17 Multi-transfer object class diagram

When a user needs a transfer object of type A, he will activate the getDataA () method of the relevant EJB to get the transfer object A; when he needs a transport object of type B, he will activate the getDataB () method to get the transfer object B; and so on. Sequence figure 18 shows this process.

Fig. 18 sequence diagram of multiple transmission objects

Using this design pattern, the entity bean of the application system and its remote interface become very simple. You no longer need to implement a set () and get () method for each member variable in the entity bean, and implement the corresponding definition in the remote interface. Users do not need to make multiple method calls to get information and data, all they need is a method call to get the entire transfer object. Of course, the tradeoff between the Web burden and a large amount of data transmission needs to be considered here. Developers can choose different implementation methods according to different needs.

As mentioned above, all data can be exchanged between the user and the entity bean by using the transfer object in one method call, that is, the transfer object works as a data carrier and reduces remote method calls, thus greatly reducing the burden on Web. By using the method of transferring objects, it will also be possible to reduce code duplication between the entity bean and its transfer objects. However, when using updatable transport object methods, users can modify their local transport object and then transfer it back to the business object, which integrates the required updates into their own side. But in this way, there will be a problem of version control, and different customers may modify the same type of transmission objects at the same time, and if the relevant business objects do not find this, it may result in the situation that some users' data is not updated in time, while others' data is overwritten; this problem must be considered in the system design.

8. Intercept filter

The intercept filter (intercepting filter) is mainly used for pre-processing and post-processing of user requests, that is, it uses additional operations for customer requests. For example, servlet can handle all customer requests for a website and provide a core authentication mechanism.

This pattern mainly works in the presentation layer and is responsible for handling different types of requests, but also requires a variety of different processing. Among these requests, some requests are sent directly to the back-end module for processing, while others are interpreted or supplemented in the filter before they can be sent to the back-end module. This mode is mainly due to the fact that a customer's Web access and system response require certain pre-processing and post-processing, such as user identity, user environment information, the legitimacy of user requests and so on. Usually, the results of these processes determine whether the user's request can be carried out, or in what format the system's response should be represented.

For this kind of preprocessing and post-processing problems, traditionally, developers design a series of additional detection program modules, that is, a complete set of if/else statements, and specify that if any of these tests fail, all processing work will exit. Obviously, this method has great disadvantages, that is, the readability and maintainability of the code will be greatly reduced, and the detection work will be integrated into the general program module, which makes it difficult to guarantee the modularity of the whole program.

The key to solving this problem is to design a simple technology to add or remove additional processing modules, which can usually perform certain detection and filtering functions. Based on what has been discussed above, J2EE researchers have proposed a design pattern-interception filter as a solution, which can implement pluggable filters to perform general processing functions without affecting the core processing module.

In theory, this filter can intercept customer requests and system responses, and perform corresponding pre-processing and post-processing; at the same time, developers can remove these filters at any time as needed without worrying about changing any other modules.

The preprocessing and post-processing functions we are talking about here usually refer to some basic system services, such as security, login, system debugging and so on. Filters that perform these functions usually need to be separated from the core modules, and these modules may be added or removed at any time due to changes in system functions or rules.

Here are some illustrations of interception filters to help you better understand this design pattern and apply it properly. Figure 19 shows the overall structure of the interception filter pattern, and figure 19 shows the participating modules in the interception filter and their relationships.

Figure 19 intercepting filter mode

Fig. 20 sequence diagram of intercepting filter

Let's illustrate each of the modules in figure 20:

(1) filter Manager (Filter Manager). The filter manager is responsible for the main processing of the filter, that is, creating the filter chain object and the corresponding filter composition, and initializing the whole process.

2) filter chain (Filter Chain). A filter chain is an ordered set of filters that are independent of each other.

Filter 1, filter 2, filter 3 (FilterOne,FilterTwo,FilterThree). These are filters that provide different services, and the filter chain is responsible for their coordination.

By adopting this design pattern, the application system can obtain more convenient central control, because the filter can provide a central module to handle a variety of requests, and can interpret and polish the user's request according to the back-end processing module, so that the request can better match the functions provided by the processing module. In addition, filters can usually aggregate different kinds of services together and provide a fairly flexible combination of services, and applications can improve their reusability by using interception filters. Filters can be inserted or removed from other program modules at any time as needed, and because they usually have standard interfaces, developers can use a similar set of filters. And reuse the whole group under different circumstances.

The adoption of this design pattern also brings some problems, that is, it will be very difficult to share information between filters because the design and development of each filter is very different according to its definition and requirements. So if you need to share information between different filters, it will be very expensive.

These are all the contents of the article "sample Analysis of value objects, transfer objects, and intercept filters in J2EE Architecture Design". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

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.