July 16, 2004
J2EE architecture design
Design of J2EE architecture: pragmatic Thursday, October 9 2003 3:30 PM one, J2EE Model - View - Controller (MVC) architecture, two, J2EE design patterns 2-1, 2-2 before the controller, the controller 2- 3, view 2-4, view help 2-5, session surface 2-6, data access object 2-7, value object or transmission object 2-8, intercept filter Reference: "J2EE Design Development Programming Guide" Rod Johnson Electronic Industry Press "J2EE Reference Daquan" JIM Keogh Electronic Industry Press "Practical J2EE Design Mode Programming Guide" Craig A.Berry Electronic Industry Press
A design pattern describes a solution for a specific design issue that combines all developers' knowledge and insights in the field of this problem; and it is also a reusable program for common problems, which generally applies to a single problem, but organizes The entire enterprise system can be provided together. Here we enumerate eight design patterns commonly used in the J2EE platform, and make a simple introduction to each model, which is convenient for everyone to learn, understand and flexibly.
1, front controller
Front Controller mainly provides a controller that can centrally manage requests, and a front controller can accept all customer requests, deliver each request to the corresponding request handle and respond properly.
The front controller is also a design mode of the layer, which is mainly due to the representation of the layer usually needs to control and coordinate multiple requests from different users, and this control mechanism can centrally control or disperse according to different needs. control. In other words, the application system requires a centralized control module for a request to represent a layer to provide a variety of system services, including content extraction, view management, and browsing. If there is no such centralized control module or control mechanism in the system, Each different system service needs to perform separate view processing, which will increase, resulting in increased system development costs; at the same time, if there is no browsing mechanism between fixed module management view, make its browsing function In each of the different views, it will eventually make the maintenanceability of the system to be destroyed; in this article, we will focus on centralized control modules, rather than decentralized control, because the former is more suitable for large-scale applications.
Based on what the problems mentioned above, the researchers put forward the design pattern of the front controller. In this mode, the controller provides a control point that handles different requests. The processing works here includes the generation of safety transactions, view selection, error handling, and response content; by the concentration of these processing work, it is greatly reduced. The Java code, while this method can also reduce the program logic of the view module to ensure a large number of logical code can be reused between different requests. Typically, both controllers work together with a dispatch component, the distribution component is mainly used for view management and browsing, which is to select the next view that should be displayed, and provides control for related display resources. Dispattered components can be included within the controller or in another separate component; although the pre-controller mode is recommended for all requests, it is not limited to one system can only have a controller. Each level in the system can have a plurality of controllers, and mapped to different system services, and Figure 2 shows the class diagram of the front controller.
Figure 2 Class diagram of the front controller
Figure 3 shows the sequence diagram of the front controller, indicating how a controller handles the relevant request.
Figure 3 Pre-controller sequence diagram
Let's discuss each component of Figure 3.
2, controller
Controller is a control point responsible for processing a variety of client requests and can put a certain function (such as user authentication, etc.) to the help class.
(1) Dispatch component (Dispatcher). One dispatch component is mainly used for view management and browsing, selecting the next view that can be displayed, and manages related display resources; distributing components can run in one controller, or as a separate component and controller Work; developers can implement static view assignment techniques in dispatch components, or complex dynamic distribution. (2) Help class. Help class is responsible for helping a view or controller to do its handles, therefore, help classes have multiple duties, including collecting data, storage intermediate data models, etc. In addition, helping classes can also ensure data integrity and accuracy Next, modify the data model for different display requirements; that is, according to the user's request, help classes can provide the view to the view unprocessed raw data, or the web content that has been formatted, one view can also help with multiple helps. The class is working together, while the latter is usually implemented by JavaBeans and tags (TAG).
3, view
View (View) is responsible for displaying information to users, and helping classes responsible for supporting views of the view, i.e., packaged and establishing a corresponding data model. Here we introduce several ways to implement controllers.
1) Based on servlet before controller
This method recommends using servlet to implement a controller, although it is different in syntax, but it is more important than using JSP; because the request processing performed by the controller is related to program operation and control flow. Although these processing work is related to the display mode, it is actually logically independent, so they are more suitable for implementation in the servlet, not in JSP technology; there are some weaknesses in the use of this method, such as servlets cannot use JSP operating environment. Resources, such as request parameters, etc., this weakness is not unable to resolve, we can establish a related handle in the servlet to access the same resource, of course, its code will become cumbersome.
2) Former controller based on JSP
This method recommends using the JSP page to implement the controller, although the syntax is the same, the servlet scheme is better than its superiority; because the logic processed by the controller is not about display mode, the controller seems to be a bit in the JSP page. The wind is not a problem; using this method is also not conducive to the distribution of the role and responsibilities of the development team, that is, software developers need to modify the request processing in the JSP page responsible for displaying logic, usually, this kind of work is quite Complex, especially consider programming, compiling, testing, and debugging errors throughout the JSP page.
3) Assignment components among the controller
If the distribution component does not have more functions, the developer can implement the component in the controller.
4) Basic front end
Based on the use of the servlet implementation controller, this program is recommended to implement a controller as a basic class, so that other controllers can be extended on it; this basic class can contain some universal logic implementations, and its subclasses will be These implementation code, this method also has a deficiencies, and when there are many subclasses inherit this basic class, and when reused the code, then a change in a class will affect all subclasses.
5) Realize the pre-controller with a filter
The filter provides a function similar to the central processing of the user request, that is, some of the controls can be implemented by a filter, which is mainly responsible for processing the interception and interpretation of the request, not requested. The generation of processing and response; usually provides a core control point for the application to handle all system services and program logic, the core control also shows that all requests can be simply tracked and recorded, thereby facilitating various services. The implementation of the function; of course, there are some shortcomings, and a small problem with a core control point may trigger the crash of the system, but in the actual development of the application system, this is not a problem, because we usually we will be on the same level. Implement multiple controllers, thereby avoiding this defect; in the controller, developers can easily implement components that check security mechanisms, so that the malicious access to the system can be shielded in the outermost layer, and the controller will also use the controller. Improve the reusability of the system module, especially when the controller uses the help class. 4, view help
View Helper is a design pattern that is a layer, a view help can include logic of data access and content display in the relevant view, and can refine the simplified view; display logic is mainly about how to format the data on how to format the page. The access logic is about how to remove the data, and the view helps usually use the JSP tag (TAG) of the data or JavaBean that reads the data.
The appearance of this design mode is mainly due to the current application system usually needs to develop display content in real time, and can process dynamic program data. If the relationship between these program data is too close, the system's representation layer often needs to be changed, so that the flexibility of the system is greatly damaged; the access logic is implemented in the same module and The display logic will affect the module of the system, which will also make the development team's task unclear.
A view typically contains formatted information and distributes its tasks to your own help class. The latter is usually implemented with JavaBeans or tag (TAG) to help classes can store the intermediate data model of the view and implement data adapters. Function, that is, appropriately transforming data format; developers can implement view components in a variety of ways, typically, developers can use JSP to implement, and this is also a recommended approach. Of course, the developer can also use servlet to implement it, which will facilitate the modularity and reusability of the application system in the help class. The system can display different data information using the same help class as different users, and displayed under different display formats; usually, if there is a large number of script code in the JSP page of the developer discovers the view, you can consider using view help. This mode is, because in this case, it is basically a program logic and display logic that has too close contact; this developer can place some logic processing for all types of requests to a certain help class. As needed, additional logic processing can also be placed in other program modules on the view layer, such as the previously discussed filter.
View helps this model design concept is mainly logical responsibility for separating application systems. Here we provide some illustrations to facilitate everyone to better understand this mode.
Figure 4 illustrates the system structure of the view help in the form of a class diagram.
Figure 4 View help class diagram
Figure 5 shows a sequence diagram of the view help mode, which indicates the main components in this mode and the operation between the mutualities; however, it is necessary to exist between the client and the view layer in many application systems. A controller is appropriately adjusted.
Figure 5 View help sequence diagram
In class chart, you can find that there may be a view without any related help classes, in which case the JSP page that usually represents the view will have some static or small number of script code. Here we are briefly introduced to the various elements in the sequence diagram:
(1) View (View). The view is responsible for displaying dynamic data information to the user, and helping classes responsible for supporting the work of the view, i.e., packaged and establishing a corresponding data model.
(2) Help class. A help class is responsible for helping view or controllers complete related processing work, including collecting data, storage intermediate model, etc .; help classes can also modify data models for different display requirements in the case of ensuring data integrity and accuracy, that is Say, according to the user's request, help classes can provide the view to the view unprocessed raw data, or the web content that has been formatted; one view can work with multiple help classes, while the latter is usually from JavaBeans and tags (tag) is achieved.
(3) Value bean (Valuebean). The value bean is actually another type of call for the help class for storing the intermediate data model, for example in the sequence diagram 5, the Business Service returns a value bean based on the request.
(4) Business Service. Business service refers to the relevant services that the user tries, the application system can provide; in general, the business service can be accessed through a business representation, while the latter is primarily to provide control and protection for business services.
Using the Help class in the view module of the application system can separate different program logic well, and provide the developer's space for the design program logic outside the view module; the help developed by JavaBean and Tag (TAG) Category usually can be reused by multiple view modules, so it also improves the reuse and maintainability of components; separating display logic from data processing logic, which is also conducive to the division of roles and characters in the development team; If the various program logic is too combined, software developers may need to modify the code in HTML, web pages and web designers need to modify page arrangements in the JSP that handles data access, which can lead to system design and development due to different The intervention of technicians produces related issues.
5, session
Session FACADE mode adjusts between cooperative corporate objects and synthesize a single and simple interface; it reduces the complexity of collaboration between classes and makes the caller when the class changes There is no need to change, this mode is usually implemented in a session bean to hide the complex interaction of the underlying EJB.
The background of this design pattern is that EJB usually includes both program data, and program logic, and these codes can act on the client layer through a certain interface, which will cause certain difficulties in multi-level J2EE platform applications.
Specifically, in a multi-level system on the J2EE platform, the following problems are usually present:
(1) Contact between levels is too close, and the business objects of the client and the backend have strong dependencies;
(2) There are multiple method calls between customers and servers, thus leading to Web performance issues;
(3) There is lacking a certain customer access mechanism so that some background objects are casually accessible.
A multi-level J2EE application typically has a number of server-side objects implemented by EJBs, which are typically responsible for providing system services, data information, etc., that is, as a business object, which includes related program data, including its program logic; In the J2EE application, the object responsible for program logic is usually implemented by session beans, and persistent storage, and the object shared between multiple users is implemented by entity beans; of course, users of the application system need to access corporate objects. Meet your needs, if the business object provides an interface to the user, the user can communicate directly with the related object, but in this way, the user must manage the relationship between the calling enterprise object, and can handle the business process between them; however If there is too direct interaction between users and business objects, the links will be too close, and the user is too much to rely too dependent on the specific implementation of the enterprise object, and is responsible for managing business objects related to interactive processes to find and creation, and Different objects are called inter-one relationship, and even sometimes the user needs to manage transaction management links between multiple calls. When user demand is increasing, this is also the case where the application system often occurs, and the interaction between users and different corporate objects will become more complex, and corporate objects may require a certain internal update to meet the needs of the former. However, the user needs to make a corresponding change in accordance with the change of the company's object, this situation will bring considerable trouble to the application system; when accessing the EJB application system, the user needs to interact with the remote object. If the user interacts directly with all related business objects, it will bring a large web burden; because the activation of each EJB will generate a remote call, and if there is a large number of system users, users and objects Interaction will bring great pressure to web communication, so that system performance is greatly damaged; if users can directly access the backend corporate objects, but the system lacks a unified user access mechanism, then these access is very likely to change There is no chaar chaotic, causing the decline in system performance, and even some security issues.
In order to solve the above problems, developers can use session design patterns, and use session beans to implement a face (FACADE) to include all related objects in a workflow; this session side is responsible for managing business objects and to users Provide a unified service access layer, the session surface can face the interaction of the underlying object, and provide a service layer that only includes the interface that must be provided, thereby separating complex object interactions and users; Manage the interaction between enterprise data and corporate objects and express the logic thereof, so the session surface can also manage the role of the enterprise object; at the same time, according to the workflow needs, the session surface also manages the creation of objects, finds , Modify and delete.
In a complex application system, the session plane can put it under the management of its lifecycle to a separate help object, for example, the session surface can hand over the management session and entity bean lifecycle to the service positioning object; In the application system, it is also very important to check the relationship between business objects. Some relationships may be temporary, that is, only to a certain interaction process, and other relationships are permanent, temporary relationships suitable for modeling Workflow in the session, a permanent relationship requires a specific condition.
The class diagram in Figure 6 briefly describes the design mode of the session surface, and Fig. 7 shows the sequence representation of the session surface, that is, the participating components and their interaction.
Figure 6 Conference plane graph
Figure 7 Conference plane sequence diagram
Here we have a brief introduction to the various components of Figure 7:
(1) Customer (Client). This means that the client of the session, that is, the client application that needs to access the relevant enterprise service, of course, can also be another session bean at the same level or different levels. (2) Session Facade. The session surface is usually implemented with session beans, which manages multiple corporate objects and provides a high-level abstract interface to users.
(3) Business object. Business object is an object that can use multiple different design, such as session beans, entity beans, and data access objects. The business objects in Figure 6 are responsible for providing data and services, while the session surface requires interaction with multiple business object instances to obtain the corresponding service.
The session is actually a control object of the business layer, which is responsible for controlling the interaction between users and corporate data and corporate service objects; in a complex application system, there may even be multiple session planes as user and object modules. Intermediary.
Here is two common methods for realizing the session.
(1) Uncleary session
When implementing the session, you should first decide whether to use the statement or stateless session bean to implement, depending on the business process modeling models modeling; if a business process only needs to be called, you can implement it. Then you can use the stateless session bean to implement it.
(2) the state of the session
When a business process requires multiple method calls to implement its services, developers are best to use state-based session beans to implement this process because the status information per method call must be saved in the session bean.
By using the session design mode in the application system, the following benefits will be obtained in the system:
1 Provide a simple interface for users and hide all interaction processes with complex system components;
2 Reduce corporate objects exposed to users, thereby reducing the dependencies between them;
3 Hide the interaction process and dependencies between the system components, making the system easier to manage, and provide considerable flexibility; provide a unified user access mechanism to facilitate administrative users for system services to request and access.
6, data access object
Data Access Object, DAO mode The data access logic is abstracted as a special resource, that is, isolates the interface of the system resources from its underlying access mechanism; packaged the data access object by picking data access, data access object Promote data access to different database types and patterns.
The background of this model is to greatly depend on the logic of data access depends on the format of the data store, such as relational database, object-oriented database, disk file, and the like.
At present, most J2EE applications require data to use sustainable data to a certain extent, and the method of achieving persistence data varies depending on the application, and the application interface (API) that accesses different storage format data is also significant. Differences; Sometimes, applications also access data stored on different operating platforms, which makes problems more complicated, usually, applications use shared distributed components such as entity beans to express persistence data. Applications can use bean-managed persistent entity beans, while in entity bean, people's agglomerate data access logic, or use container management persistent entity beans to manage all transactions and persistent details; if the application is Data Access is very simple, or you can read and modify data using session beans or servlets directly access persistence stores.
Some applications can use the JDBC application interface to access data in the relational database, JDBC is responsible for general persistence data access and management, in the J2EE application, can embed SQL statements in JDBC, to access relational databases, of course Different database types, the language and syntax of the SQL statement will also be different; Document, the access logic of their respective data has a thousand autumn, which has caused the dependencies between program code and data access code; when the program component, that is, entity bean, session bean or servlet, JSP, etc., they will Use the correct application interface to get connected and manage the data source, but this will also cause dependencies between these components and data source physical implementations, so that the application is difficult to transplant from one data storage entity to another. During the way; when the physical implementation of the data source changes, the application must also change accordingly. Based on the problems discussed above, developers begin to use data access objects. Data Access Objects actually include objects for all data access logic, and manage the connection to the data source, depending on the data source, the data access object implements different access mechanisms, and the data source mentioned here can be persistent. Storage media, such as relational databases, can also be external services, such as Data exchange, not only user, but also other components in the application system, or data access interfaces provided by data access objects, data access objects The physical implementation details of the data source are completely separated, and when the underlying data source changes, the interface provided by the data access object will not change to the user; this method allows the application system to use the data access object to accommodate more Data storage media, in summary, data access object is an adapter in the middle of the system components and data sources.
The class diagram in Figure 8 represents the participation object and the call relationship between the data access object design mode, and Fig. 9 is a sequence diagram of such a design mode.
Figure 8 Data Access Object Class Map
Figure 9 Data Access Object Sequence Diagram
The components in the sequence diagram of Figure 9 are explained as follows:
(1) Business object. Users indicating data that requires access to data, and a business object can be implemented with a session bean, entity bean, or another Java program.
(2) Data Access Objects (Data Access Object). Data Access Objects is the topic in this mode, which provides objects for underlying data access, and provides it to business objects to enable the latter to transparently access data sources; while business objects also hand over data loading and storage operation Handle data access objects.
(3) Data Source. Here, it refers to the physical implementation of the data source, which can be a database, including relational databases, object-oriented databases or file systems.
(4) Transfer object. The transmission target here refers to a data carrier. Data Access Objects can use the transfer object to return data to the user, and the data access object can also get the data source to update the data in the data source from the user.
The following is given a method of implementing data access object design modes.
(1) Automatic data access object code generation
Since each business object corresponds to a data access object, the developer can establish a relationship between business objects, data access objects, and underlying implementation; once this relationship is established, developers can write special access objects for all data access objects. Code generation tool.
Information generating data access objects is typically stored in a description file defined by a developer. If the requirements for data access objects are too complex, developers can consider using third-party tools to provide object pairs of relationships for relational databases. These tools are usually some GUI programs that can be used to map business objects as persistent storage objects, and define the traffic-operated data access objects. When the mapping is completed, these tools can automatically generate code, and provide some corresponding Function, such as cache results, caching query, integration with application servers, integration with third-party products, etc. (2) Data Access Object Agent (Factory for Data Access Objects)
When the underlying data storage does not change easily, the developer can take this method to achieve the corresponding, data access object, and Figure 10 is a class diagram of this method.
Figure 10 Using 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 proxy and various types of actual data access object agents, each Objects correspond to a persistent storage medium, once components get these agents, they can use to create data access objects that need to use.
Figure 11 shows the class diagram of this case. This type of diagram represents a base data access object agent, which is an abstract class that is inherited by other actual data access object proxy to support specific data access functions; users can get an actual data access object and take advantage of it To create the required data access objects to access the relevant data, each actual data access object is responsible for establishing the connection to the data source and gets supported by the support.
Figure 11 Abstract agent uses DAO
12 is a sequence diagram in this case.
Figure 12 Abstract agent uses a DAO sequence diagram
The advantages of this design pattern:
Transparent is good. Business objects can access data without knowing the data source implementation details. Since all data access details are hidden by the data access object, this access process is transparent.
It is good to be portable. Adding a data access object in an application system, it can make the former can easily port to another database implementation. The business object is isolated from the data implementation, so in the transplantation process, only some changes in the data access object can be made.
Reduce the code complexity of the business object. Since data access objects can manage all data access complex details, this also simplifies the code of business modules and other data clients. At the same time, it also improves the overall readability and development rate of the application system.
Convert all data access. Since all data access operations are handed over to data access objects, other parts of the application system are separated from data access, and all related operations are related to data access objects, which also makes relevant operations more easily maintained and managed. .
This design pattern is defective:
The persistence of container management cannot be utilized. If the EJB container takes a container management, all managers are responsible for persistent data storage. Such an application system does not need to implement data access objects because the application service provides this feature transparently.
Add additional levels. Data Access Objects adds a level between data users and data sources, increasing some additional design and implementation burdens. Of course, we think it is worthwhile.
In summary, when developers choose different modes, it should be noted that a certain pattern corresponds to a certain application level. For example, the mode related to the view and display is applied in the web layer. Some modes related to business logic control are related to the EJB level. Other than some mode of reading data and assignment operations are applicable to between different hierarchies.
7, value object or transmission object
Value Object mode promotes data exchange by reducing messages of distributed communication, usually herein referred to herein between the Web layer and the EJB layer. In a remote call, a single value object can be used to take out a series of related data and provide customers.
The appearance of this design pattern is based on the case where the customer needs to exchange data from EJB. Specifically, in the J2EE platform, the application system typically implements the server components of the server as session beans and entity beans, and some of these components need to return data to customers; in this case, usually one user will be repeatedly called The relevant method is multiple times until it gets related information, it should be noted that most of the cases these method calls are to obtain a single information, such as username or user address, and the like. Obviously, in the J2EE platform, this call is basically from a remote. That is, the user will call the corresponding method to bring a great burden to the Web, even if the user and the EJB container load the same JVM, OS and computer running the EJB program, because the method call is default it is a remote task. Therefore, this problem still exists.
Due to the problems mentioned above, the relevant application performance will have a big decline when the number of calls of the remote method is increased, so the single information is used to obtain a single information; In the case, J2EE's researchers are recommended to use transmission objects to include all program data, that is, each method call can send and receive this transmission object; when the user issues a request for program data to the EJB, EJB creates this transfer object, Passing its individual domains with related values and transmits the entire object to the user.
When EJB uses a transfer object, the user can obtain the entire object by only one way to call, rather than using multiple method calls to obtain the value of each domain in the object; due to the transfer object is delivered to the user Therefore, all calls or values for this transmission object are local calls, not remote methods calls. However, it should be noted that this transmission object must have an access method corresponding to each attribute, or all attributes are set to public.
Class Figure 13 shows the architecture of the transmission target mode.
Figure 13 Transport object class diagram
In Figure 13, the transmission object is first created in the EJB and then returns to the remote customer; of course, the transmission object can also fuse the other design modes as needed.
Figure 14 shows the interaction between the participating modules in the transmission object mode and between them.
Figure 14 Transfer object sequence diagram
Below we explain the various participatory modules of the transfer object mode:
(1) Customer (Client). The customer represents the user provided by EJB, usually the application running on the user terminal.
(2) Business objects. Business objects represent characters implemented by session beans, entity beans or data access objects in a mode. Business objects are typically responsible for creating a transfer object and transmitting it to related users based on requests; business objects can also get data in a transmission object format, and apply data to perform some updates.
(3) Transfer objects. Transfer objects are a sequentially-sequentially-sequential Java object. In this object class, there is usually a constructor containing all domains to create this transfer object.
The member variables in this transport object are basically defined as public, so there is no need to provide relevant access methods for them. Of course, if there is a safe need, the associated member variables can also be set to protected or private, and each access method is given. It can be seen that the design of the transmission object is changed as the application system needs to be different, and the member variables in the object are set to public, or provide a certain access method, will be an important design problem.
Usually, when this mode is implemented, you can take up to updatable transmission object policies and multi-transmission object policies. In an updated transfer object policy, the transfer object can not only achieve relevant information and data from the service object of the user, but also from the service object to the user's changes to the data.
Figure 15 shows the relationship between business objects and transmission objects in the form of a class chart.
Figure 15 can be updated transport object class diagram
Business object creates a transfer object. The user has access to the information, and has made a certain amount of information, and the relevant data must be made; in order to enable the user to modify the value of the various domains of the business object, this object must provide a certain variable value method, and For the consideration of the Web burden, the method provided by the business object is best used as a parameter of the transmission object. Accordingly, these methods can call the method provided by the transfer object to set the value of each member variable of the transfer object; and in the method of transmitting the object, we can also implant the logic of data verification and integrity checks, so When the user gets a transmission object from the method of the business object, the member method of the transfer object can be directly called for local data access, and of course this local data access does not affect the business object. When the user calls the variable value method of the business object, the method seizes the transmitted object of the client, and then sends it to the business object; the business object receives the updated transmission object, and the update is written back to their object copy. In the middle; here, the above mentioned writes are only involved in the updated variable, not the write back of all variables, so we need to set another variable in the transfer object to specify which member variables are users Overhailed, this also makes this model relatively complex, developers need to consider synchronization and version control issues.
Figure 16 shows the sequence diagram of this update process.
Figure 16 can update the transmission object sequence diagram
Multi-transmission object method refers to a single business object to create multiple different transmission objects according to user requests. That is, the business object and the transfer object it created have a pair of relationships. Class Figure 17 represents various participatory modules of this implementation method and the call relationship between them.
Figure 17 Multi-transmission object class diagram
When a user needs a type A transmission object, he activates the relevant EJB's getDataA () method to get the transfer object a; when he needs a B type transfer object, he activates the getDatabase () method to get the transfer object B; So on and so forth. Sequence Figure 18 shows this process.
Figure 18 Multi-transmission object sequence diagram
Using this design pattern, the entity bean and its remote interfaces of the application system will become very simple. There is no need to implement a SET () and get () method in the entity bean, and implement the corresponding definition in the remote interface. The user does not need to make multiple method calls to obtain information and data, and only one method call to obtain the entire transfer object. Of course, you need to consider the Web burden and the trade-off of a large amount of data. Developers can choose different implementation methods according to different needs.
As described above, the user and entity bean can be exchanged between all data by using a transmission object in a method call, that is, the transmission object is operated as a data carrier, and reduces the remote method call, thereby greatly reduces the Web burden. . By using a method of transfer objects, we will also reduce the code duplication between entity beans and its transmission objects. However, when using the updateable transmission object method, the user can modify its local transmission object, then transfer it back to the business object, the latter will integrate the update to one end; but in this way, it will exist A version control problem, different customers may modify the same type of transfer object, and if the relevant business object does not find this, it may result in some users 'data without timely update, while others' data The situation is covered; this problem must be considered in the system design.
8, intercepting the filter
Intercepting filter is mainly used for processing and post-processing for user requests, that is, it uses additional operations for customers' requests. For example, servlet can handle all customer requests for a website and provide a core authentication mechanism.
This mode is mainly working in the representation, which is responsible for handling different types of requests, but also requires a variety of different processing. In these requests, some requests will be transferred directly to the backend module, while others will first interpret or supplement content in the filter, and then transfer to the backend module. The proposal of this mode is mainly due to a customer's web access and system response requires certain pre-processing and post-processing, such as user identity, user environment information, legitimacy of user requests. Usually the results of these processing will determine if the user's request can be performed, or the system's response should be used in what form is represented. For this pretreatment and post-processing, traditionally, developers will design a series of additional detection program modules, which is a set of IF / ELSE statements, and specify if any of the detection failures, all processing work will exit. Obviously, this method is a great shortage, that is, the readability of the code will be greatly reduced, and the detection work is integrated into the general program module, so that the module of the entire program is difficult to guarantee.
The key to solving this problem is to design a simple technology to add or remove additional modules, and these modules are usually capable of completing certain detection and filtering. According to the above discussion, J2EE researchers put forward the design mode ---- intercepting the filter as a solution, this mode can implement the insertable filter without affecting the core processing module to perform a general processing function.
In theory, such filters can intercept customer requests and system responses, and perform corresponding pretreatment and post-processing; while developers can also remove these filters at any time, do not have to worry about any other modules.
We will refer to some basic system services, such as security, login, system commissioning, and more. Filters that perform these functions are usually separate from core modules, and these modules may be added or deleted at any time due to system functions or rules.
Some about the illustration of intercepting the filter is provided to help you better understand this design mode and apply reasonably. Figure 19 shows an overall structure of the filter mode, and Figure 19 shows the intercepting modules and intercepts between the filters.
Figure 19 Intercepting the filter mode
Figure 20 Intercepting filter sequence diagram
Here we respect each of the modules in Figure 20:
(1) Filter Manager. The filter manager is responsible for the main processing of the filter, that is, create a filter chain object, and the corresponding filter, and initializes the entire processing process.
(2) Filter chain. The filter chain is an ordered set of mutually dependent filters.
(3) Filter 1, filter 2, filter 3 (Filterone, FilterTwo, FilterThree). These are filters that provide different services, while the filter chain is responsible for their coordination work.
By adopting this design mode, the application system can achieve more convenient center control, which is because the filter can provide a central module that handles a plurality of requests, and can interpret and touch the user's request according to the rear end processing module, so that the request It can better match the functionality provided by the processing module. Additionally, the filter can usually collect different kinds of services together and provide a fairly flexible service combination, the application system can increase its reuse by using the intercept filter, the filter can be inserted or shifted from other program modules at any time as needed. Except, and because they usually have standard interfaces, developers can use a set of filters and carry out all sets of reuse in different situations.
This design pattern will also bring a certain problem, that is, sharing information between the filters will become very difficult, which is due to its definition and demand, each filter design and development is large. Therefore, if you need to share information between different filters, the cost will be very expensive. ================================ Author: pragmatic, for many years engaged in the development and application of J2EE applications and Web site projects.
Reference:
"J2EE Design Development Programming Guide" Rod Johnson Electronic Industry Press
"J2EE Reference Daquan" JIM Keogh Electronic Industry Press
"Practical J2EE Design Mode Programming Guide" Craig A.Berry Electronic Industry Press
