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

It is believed that many inexperienced people have no idea about how to analyze J2EE model and J2EE design pattern. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

At present, most enterprises adopt the structure design and solution of J2EE technology. For us to study and study J2EE architecture, it is necessary to understand and master the design methods and some common patterns of J2EE architecture. Model-view-control (MVC) structure is the most common architecture on which J2EE applications are based. MVC is mainly suitable for interactive Web applications, especially with a large number of pages and multiple customer visits and data display. Comparatively speaking, a workflow architecture is more used in the case of process control and less interaction; in addition to the architecture, the design pattern of J2EE is also very helpful for us to solve the design of application systems.

1. The model-view-control (MVC) architecture of J2EE

Model-view-control architecture is a widely used architecture for interactive applications. It effectively distinguishes functional modules in objects that store and display data to reduce the connectivity between them. this architecture transforms the traditional input, processing and input model into a graphical user interaction model, or, to put it another way, multi-level Web business applications. The MVC architecture has three layers: Model, View and Controller, each of which has its own function. The MVC architecture is as follows:

Figure 1 MVC architecture

The model layer is responsible for expressing and accessing business data and performing business logic and operations. In other words, this layer is the software simulation of real-life functions; when the model layer changes, it notifies the view layer and provides the latter with the ability to access its own state. at the same time, the control layer can also access its functions to complete related tasks.

The view layer is responsible for displaying the contents of the model layer. It takes data from the model layer and specifies how the data is displayed. It will be updated automatically when the model layer changes. In addition, the view layer also transmits the user's input to the controller.

The control layer is responsible for defining the behavior of the application. It can dispatch user requests and select the appropriate view for display, and it can also interpret user input and map them to actions that can be performed at the model layer; in a graphical interface, common user input includes clicking buttons and menu selections. In Web applications, it includes requests for HTTP GET and POST at the Web layer The control layer can select the next view that can be displayed based on the interaction of the user and the operation results of the model layer. an application usually sets a module of the control layer based on a set of related functions. even some applications have different control layer settings according to different user types, mainly because the view interaction and selection of different users are also different.

Dividing responsibilities between the model layer, the view layer, and the control layer reduces the repetition of the code and makes the application easier to maintain. At the same time, due to the separation of data and business logic, data processing becomes easier when new data sources are added and data display changes.

II. J2EE design pattern

A design pattern describes a validated solution to a particular design problem, which integrates the knowledge and insights of all developers on the domain of the problem; it is also a reusable solution for common problems, which are generally suitable for a single problem, but organized together can provide a solution for the entire enterprise system. Below, we list eight design patterns commonly used in the J2EE platform, and briefly introduce each pattern, which is convenient for everyone to learn, understand and apply flexibly.

1. Front controller

The front controller (front controller) mainly provides a controller that can centrally manage requests. A front controller can accept all customer requests, submit each request to the corresponding request handle, and respond to the user appropriately.

The front controller is also the design pattern of the presentation layer, which is mainly due to the fact that the presentation layer usually needs to control and coordinate multiple requests from different users, and this control mechanism may be centralized or decentralized according to different needs. In other words, the application system needs to provide a centralized control module for the presentation layer requests 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 separate view processing, so the repeatability of the code will be improved, resulting in higher system development costs. At the same time, if there is not a fixed module to manage the browsing mechanism between views, so that the browsing function is decentralized to each different view, the maintainability of the system will eventually be destroyed; in this paper, we mainly discuss the centralized control module, rather than decentralized control, because the former is more suitable for large-scale application systems.

Based on the problems mentioned above, the researchers proposed the design pattern of the pre-controller. In this mode, the controller provides a control point to handle different requests, where the processing includes security transactions, view selection, error handling and response content generation; by concentrating these processing work on one point, the amount of Java code is greatly reduced. at the same time, this method can also reduce the program logic in the view module, ensuring that a large amount of logic code can be reused between different requests. Usually, the controller works jointly with a dispatch component, which is mainly used for view management and browsing, that is, to select the next view that should be displayed for the user, and to provide control over the relevant display resources. The dispatch component can be included in the controller or in a separate component; although the front controller model recommends unified processing for all requests, it is not limited to having only one controller in a system. There can be multiple controllers at each level of the system and mapped to different system services. Figure 2 below shows the class diagram of the front controller.

Fig. 2 class diagram of the front controller

Figure 3 shows a sequence diagram of the front controller, showing how a controller handles related requests.

Fig. 3 sequence diagram of front controller

Let's discuss the various components of figure 3.

2. Controller

The controller is the control point responsible for handling various customer requests and can delegate certain functions (such as user authentication, etc.) to the helper class.

(1) dispatch components (Dispatcher). A dispatch component is mainly used for view management and browsing, selecting the next view that can be displayed for the user, and managing related display resources; the dispatch component can run in a controller, or work with the controller as a separate component; developers can implement static view dispatch technology or complex dynamic dispatch in the dispatch component.

(2) help class (Helper). The helper class is responsible for helping a view or controller to complete its processing, so the helper class has a number of responsibilities, including collecting data, storing intermediate data models, etc.; in addition, helper classes can also ensure the integrity and accuracy of the data. modify the data model for different display requirements That is, at the request of the user, the helper class can provide unprocessed raw data or formatted Web content to the view, and a view can work with multiple helper classes at the same time, which is usually implemented by JavaBeans and tag.

3. View

The view is responsible for displaying information to the user, while the helper class is responsible for supporting the view, that is, packaging and building the corresponding data model. Here are several ways to implement the controller.

1) based on Servlet front controller

This approach suggests using servlet to implement a controller, which, although almost syntactically similar, is superior to using JSP; because most of the request processing performed by the controller is related to program running and control flow, although it is related to the display mode, it is actually logically independent, so they are more suitable for implementation in servlet rather than in JSP technology. There are some weaknesses in using this method, for example, servlet cannot use the resources of the JSP runtime environment, such as request parameters, but this weakness can not be solved. We can set up relevant handles in servlet to access the same resources, of course, the code will become a little more cumbersome.

2) the front controller based on JSP

This approach suggests using JSP pages to implement the controller, although the syntax is the same, but the Servlet scheme is superior to it; because the logic handled by the controller is generally not related to the display mode, it seems a bit irrelevant to implement the controller in the JSP page. Using this approach is also not conducive to the allocation of roles and responsibilities of the development team, that is, software developers need to modify the code that handles the request in the JSP page responsible for displaying logic, which is usually quite complex, especially considering the programming, compilation, testing, and debugging errors of the entire JSP page.

3) dispatching components in the controller

If the dispatch component does not have more functionality, the developer can implement the component in the controller.

4) basic front end

Based on using servlet to implement the pre-controller, this scheme suggests implementing a controller as the base class, so that other controllers can be extended on top of it. This basic class can contain some general logic implementations, and its subclasses will overload the implementation code, and this approach also has some drawbacks, when many subclasses inherit the basic class and reuse a large number of code. then it is possible that a change in one class will affect all subclasses.

5) implement the front controller with filter

The filter provides functions similar to the central processing of user requests, that is, some functions of the controller can be implemented by the filter, which is mainly responsible for handling the interception and interpretation of the request, rather than the processing of the request and the generation of the response. Usually, a core control point can be provided for the application system to handle all system services and program logic, and the core control indicates that all requests can be simply tracked and recorded, thus facilitating the implementation of various service functions. Of course, it also has some shortcomings, a small problem of a core control point may cause the system to crash, but in the actual development of the application system, this is not a problem, because usually we will implement multiple controllers on the same level, thus avoiding this defect. In the controller, developers can easily implement a component that checks the security mechanism, which can shield malicious access to the system at the outermost layer, and the use of the controller will also improve the reusability of the system module. especially when the controller uses helper classes at the same time.

4. View help

View help (View helper) is a design pattern that belongs to the presentation layer, a view help can contain the logic of data access and content display in related views, and can refine and simplify the view; the display logic is mainly about how to format the data on the page, and the access logic is about how to extract the data, the view help is usually used to display the data JSP tags (tag) or read the data JavaBean.

The emergence of this design pattern is mainly due to the fact that current application systems usually need to develop display content in real time and can deal with dynamic program data. If the relationship between the access logic and display logic of these program data is too close, the presentation layer of the system will often need to be changed, thus the flexibility and reusability of the system will be greatly destroyed. at the same time, the implementation of access logic and display logic in the same module will affect the modularization of the system and make the task division of the development team unclear.

A view usually contains formatting information and distributes its processing tasks to its own helper class, which is usually implemented in JavaBeans or tag. The helper class can also store the intermediate data model of the view and implement the function of the data adapter, that is, convert the data format appropriately Developers can implement view components in a variety of ways. In general, developers can use JSP to implement them, and this is a recommended approach. Of course, developers can also use Servlet to implement it, and implanting some program logic in the view into the help class will be conducive to the modularization and reusability of the application system. The system can use the same helper class to display different data information for different users and display it in different display formats; in general, if developers find that there is a lot of script code in the JSP page of the view, they can consider using the view help mode, because in this case, it is basically because the program logic and display logic are too closely related. At this point, developers can put some logical processing that is applicable to all types of requests into certain help classes, and as needed, they can also place other logical processing in other program modules on the view layer. such as the interception filter discussed earlier.

The design idea of the view to help this pattern is mainly to separate the logical responsibilities of the application system. Here are some illustrations to make it easier for you to better understand the pattern.

Figure 4 illustrates the system structure of view help in the form of a class diagram (class diagram).

Figure 4 View help class diagram

Figure 5 shows a sequence diagram of the view help pattern, which shows the main components of this pattern and how it works with each other, but it should be noted that in many applications, there will be a controller between the client and the view layer to make appropriate adjustments.

Figure 5 View help sequence diagram

In the class diagram, you can see that there may be views without any related helper classes, in which case the JSP page that usually represents the view will have some static or small amount of script code.

Here we give a brief introduction to the elements in the sequence diagram:

(1) View (view) The view is responsible for displaying dynamic data information to the user, while the helper class is responsible for supporting the view, that is, packaging and building the corresponding data model.

(2) help class (helper). A helper class is responsible for helping the view or controller to complete the related processing work, including collecting data, storing intermediate models, etc.; the helper class can also modify the data model for different display requirements while ensuring the integrity and accuracy of the data, that is, according to the user's request, the helper class can provide the view with unprocessed raw data or formatted Web content A view can work with multiple helper classes at the same time, which is usually implemented by JavaBeans and tag.

(3) value bean (ValueBean). The value bean is actually another name for the helper class used to store the intermediate data model. For example, in sequence figure 5, business service returns a value of bean upon request.

(4) Business Services (business service). Business service refers to the relevant services that users try to get and the application system can provide; generally speaking, business services can be accessed through a business representative (business delegate), which mainly provides control and protection of business services.

The use of helper classes in the view module of an application system can well separate different program logic and provide space for developers to design program logic outside the view module; help classes developed based on JavaBean and tag can usually be reused by multiple view modules, thus improving the reusability and maintainability of components The separation of display logic from data processing logic is also beneficial to the division of roles and characters in the development team. For example, if all kinds of program logic are too combined, software developers may need to modify the code in HTML and web pages, while Web designers may need to modify the page layout in the JSP that handles data access, all of which may lead to related problems in system design and development due to the intervention of different technicians.

5. Conversation face

The session facade mode adjusts operations between cooperative enterprise objects and synthesizes application functions into a single and simple interface; it reduces the complexity of cooperation between classes and makes the callers of classes do not need to change when the class changes. This mode is usually implemented as a session bean to hide the complex interactions of the underlying ejb.

The background of this design pattern is that EJB usually includes both program data and program logic, and these codes will act on the client layer through a certain interface, which will cause some difficulties in multi-level J2EE platform applications.

Specifically, in a multi-tier system on the J2EE platform, there are usually the following problems:

(1) the relationship between the layers is too close, and there is a strong dependency between the customer layer and the back-end business objects.

(2) there are multiple method calls between the client and the server, which leads to problems in Web performance.

(3) lack of certain customer access mechanism, so that some background objects are accessed casually.

A multi-level J2EE application usually has many server-side objects implemented by EJB, which are usually responsible for providing system services, data information, etc., that is, as business objects, they include both relevant program data and their program logic. In J2EE applications, objects responsible for program logic are usually implemented by session bean, while objects that represent persistent storage and are shared among multiple users are implemented by entity bean Of course, users of the application system need to access the enterprise object to meet their needs. If the enterprise object provides an interface to the user, the user can communicate with the relevant object directly, but in this way, the user must be responsible for managing the relationship between the called enterprise objects and be able to handle the business processes between them However, if there is too direct interaction between the user and the business object, the relationship between the two will be too close, and at the same time, the user will be too dependent on the specific implementation of the enterprise object. and is responsible for managing the search and creation of business objects related to the interaction process, as well as the relationship between different objects calling each other, and even in some cases users need to manage the transaction management between multiple calls.

When the user demand is increasing, this is also a frequent occurrence of the application system, and the interaction between the user and different enterprise objects will become more and more complex, and the enterprise object may need some internal updates to meet the needs of the former, but in this case, the user needs to make corresponding changes according to the changes of the enterprise object implementation, which will bring considerable trouble to the application system. When accessing the EJB application system, users need to interact with remote objects. If the user interacts with all relevant business objects directly, it will bring a great burden on Web, because for each activation of ejb, there will be a remote call, and if there are a large number of system users, the interaction between users and objects will bring great pressure on Web communication and greatly damage the performance of the system. If users can directly access the back-end enterprise objects, but there is a lack of a unified user access mechanism in the system, then these visits are likely to become disorganized, resulting in a decline in system performance, and even lead to some security problems.

In order to solve the above problems, developers can adopt the design pattern of session bean, even if a session bean is used to implement an facade to contain the interaction of all related objects in a workflow. This session is responsible for managing business objects and provides users with a unified service access layer, which can be oriented to the interaction process of the underlying objects and a service layer that contains only the interfaces that must be provided. as a result, it isolates complex object interactions from users. The session surface is also responsible for managing the interaction between enterprise data and enterprise objects, and expressing the enterprise logic needed in it, so the session surface can also manage the functional relationship between enterprise objects; at the same time, according to the needs of workflow, the session surface also manages the creation, lookup, modification and deletion of objects.

After reading the above, have you mastered how to analyze J2EE models and J2EE design patterns? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.