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

This article introduces J2EE MVC architecture and its design pattern, the content is very detailed, interested partners can refer to, I hope to help you.

At present, most enterprises adopt J2EE technology for structure design and solution. For us to learn and study J2EE architecture, it is necessary to understand and master the design methods and some common patterns of J2EE architecture; Model-View-Control Model-view-control (MVC) architecture is the most common J2EE application architecture. MVC is mainly suitable for interactive Web applications, especially for large number of pages, multiple customer visits and data display. In comparison, a workflow architecture is more applied to process control and less interaction. In addition to architecture, J2EE design patterns are also helpful for us to solve the design of application systems.

J2EE Model-View-Control (MVC) Architecture

Model-view-control architecture is a widely used architecture for interactive applications. It effectively distinguishes functional modules among objects that store and display data to reduce connectivity between them. This architecture transforms the traditional input, processing, and input models into graphical user interaction models, or in other words, multi-layered Web business applications. The MVC architecture has three layers: Model, View, and Controller, each with its own functional role. The MVC architecture is as follows:

J2EE MVC Architecture and Its Design Pattern

Figure 1 MVC architecture

The model layer is responsible for expressing and accessing business data, performing business logic and operations. That is, this layer is a software simulation of real-life functionality; it informs the view layer when the model layer changes and provides the latter with access to its own state, while the control layer can access its functional functions to perform 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 that data is displayed. It will update automatically as the model layer changes. The view layer also transmits user input to the controller.

The control layer is responsible for defining the behavior of the application. It dispatches user requests and selects the appropriate view for display, while it interprets user inputs and maps them to actions that can be performed at the model level; common user inputs in a graphical interface include button clicks and menu selections. In Web applications, it includes HTTP GET and POST requests to the Web layer; the control layer can select the next view that can be displayed based on user interactions and the results of model layer operations; an application will usually set a control layer module based on a set of related functions, and even some applications will have different control layer settings according to different user types, mainly because different users have different view interactions and choices.

Splitting responsibilities between the model, view, and control layers reduces code duplication and makes application maintenance easier. Also, because of the separation of data and business logic, data processing becomes easier as new data sources are added and data displays change.

J2EE design patterns

A design pattern describes a validated solution to a particular design problem that combines all developers 'knowledge and insights into the domain of the problem, and reusable solutions to common problems that are generally applicable to a single problem, but organized together to provide a solution for an entire enterprise system. Below we list eight design patterns commonly used in J2EE platform, and give a brief introduction to each pattern for everyone to learn, understand and flexibly apply.

1. Front controller

A 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 appropriately to the user.

The former controller is also a design pattern of the presentation layer, which appears mainly because 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 request of the presentation layer to provide various 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 be processed separately, so that the code repeatability will increase, resulting in increased system development cost. At the same time, if there is no fixed module to manage the browsing mechanism between views, the browsing function will be decentralized to each different view, and eventually the maintainability of the system will be destroyed. In this paper, we mainly discuss centralized control modules rather than decentralized control, because the former is more suitable for large application systems.

Based on the above questions, the researchers proposed a design model for the front controller. In this pattern, the controller provides a control point for processing different requests, including security transactions, view selection, error handling, and response content generation; by concentrating these processing tasks in one point, the Java code volume is greatly reduced, and this approach also reduces the program logic in the view module, ensuring that a large amount of logic code can be reused between different requests. Typically, controllers work in conjunction with a dispatch component that is primarily used for view management and browsing, i.e., selecting the next view to display for the user and providing control over the associated display resources. The dispatch component can be contained within the controller or in a separate component; although the pre-controller pattern recommends uniform processing for all requests, it is not limited to one controller in a system, and multiple controllers can be present at each level of the system and mapped to different system services. Figure 2 below shows the pre-controller class diagram.

Figure 2 Class diagram of the front controller

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

Figure 3 Sequence diagram of front controller

Let's discuss the components of Figure 3.

2. Controller

A controller is a control point responsible for handling various customer requests and can delegate certain functions (such as user authentication) to the help class.

(1)Dispatcher. A dispatch component is primarily used for view management and browsing, selecting the next view to display for the user, and managing the associated display resources; the dispatch component can run within a controller or work with the controller as a separate component; developers can implement static view dispatch techniques in the dispatch component, or complex dynamic dispatch.

(2)Help Category (Helper). Help class is responsible for helping a view or controller to complete its processing work. Therefore, help class has many responsibilities, including collecting data, storing intermediate data model, etc. In addition, help class can also modify data model for different display requirements under the condition of ensuring data integrity and accuracy. That is, depending on the user's request, help classes can provide raw data or formatted Web content to a view, and a view can work with multiple help classes at the same time, which are usually implemented by JavaBeans and tags.

3. View

Views are responsible for displaying information to the user, and help classes are responsible for supporting the work of the view, that is, packaging and building the corresponding data model, we introduce several ways to implement the controller.

1) Servlet-based front controller

This approach suggests using servlets to implement a controller, although syntactically similar, but it is better than using JSP to implement; because most of the request processing performed by the controller is related to program execution and control flow, although these processing tasks are related to display mode, they are actually logically independent, so they are more suitable for implementation in servlets than JSP technology; There are also some weaknesses in this approach, such as servlet can not use JSP runtime environment resources, such as request parameters, etc., but this weakness is not unsolvable, we can establish the relevant handle in the servlet to access the same resources, of course, its code will become a bit cumbersome.

2) JSP-based front controller

This approach suggests using JSP pages to implement the controller, although syntactically the same, but Servlet scheme is superior to some; because the controller is generally not dealing with the logic of the display mode, so in JSP pages to implement the controller seems a bit irrelevant; Using this approach is also detrimental to the assignment of roles and responsibilities to the development team, i.e., the software developer needs to modify the request processing code 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) Dispatch component in controller

If the dispatch component does not have much functionality, developers can implement it in the controller.

4) Basic front end

Based on the use of servlets to implement a pre-controller, this approach suggests implementing a controller as a base class so that other controllers can extend on top of it; this base class can contain some common logical implementations, and its subclasses overload these implementation code. This approach also has certain drawbacks. When many subclasses inherit the base class and reuse code heavily, it is possible that a change in one class will affect all subclasses.

5) Implement front controller with filter

Filters provide functionality similar to central processing of user requests, that is, some of the functionality of the controller can be implemented by filters, which are primarily responsible for handling interception and interpretation of requests rather than processing requests and generating responses; A core control point can usually be provided for the application system to handle all system services and program logic. The core control also indicates that all requests can be easily tracked and recorded, thus facilitating the implementation of various service functions. Of course, it also has some shortcomings. A small problem with 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 we usually implement multiple controllers at the same level, thus avoiding this defect. In the controller, developers can easily implement a component that checks security mechanisms, thereby shielding malicious access to the system at the outermost level, and using the controller also improves the reusability of system modules, especially if the controller also uses helper classes.

4. View Help

View helper is a design pattern belonging to the presentation layer. A view helper can contain the logic of data access and content display in the relevant view, and can refine and simplify the view; display logic is mainly about how to format the data on the page, while access logic is about how to extract the data. View helper is usually used to display JSP tags of data or JavaBeans for reading data.

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

A view usually contains formatting information and distributes its processing tasks to its own help class, which is usually implemented with JavaBeans or tags. The help class can also store the intermediate data model of the view and implement the function of data adapter, that is, appropriately transform the data format; developers can implement view components in a variety of ways, usually, developers can use JSP to implement, and this is also a recommended method. Of course, developers can also use Servlet to implement it accordingly. Implanting certain program logic in the view into the help class will benefit the modularization and reusability of the application system. The system can use the same help class to display different data information for different users and display it in different display formats; usually, if developers find that there is a large amount of script code in the JSP page of the view, they can consider using this mode of view help, because in this case, the program logic and display logic are basically too closely related; The developer can then place some of the logical processing that applies to all types of requests into certain helper classes, and optionally, other logical processing in other program modules at the view level, such as the interception filters discussed earlier.

Views help this pattern is designed primarily to separate the logical responsibilities of the application system. Here are some diagrams to help you understand this pattern better.

Figure 4 illustrates the system structure of View Help in class diagram form.

Figure 4 View Help Class Diagram

Figure 5 shows a sequence diagram of the View Help pattern, showing the main components of the pattern and how they work with each other; however, it should be noted that in many applications, there is a controller between the client and view layers to adjust appropriately.

Figure 5 View Help Sequence Diagram

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

Here is a brief description of the elements in the sequence diagram:

(1)View (view). Views are responsible for displaying dynamic data information to users, while help classes are responsible for supporting views, that is, packaging and building corresponding data models.

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

(3)Value bean(ValueBean). A value bean is actually another name for a helper class that stores an intermediate data model, for example, in sequence figure 5, a business service returns a value bean upon request.

(4)Business services (business services). A business service is a service that an application system can provide that a user is trying to obtain; typically, a business service can be accessed through a business delegate, which mainly provides control and protection for the business service.

Using help class in view module of application system can separate different program logic well, and provide space for developers to design program logic outside view module; help class developed based on JavaBean and tag can be reused by multiple view modules, so it also improves the reusability and maintainability of components; separating display logic from data processing logic is also beneficial to the division of roles and characters in development team; For example, if the various program logic is too integrated, software developers may need to modify the code in HTML, Web pages and Web designers need to modify the page layout in JSP handling data access. These situations may lead to problems related to system design and development due to the intervention of different technical personnel.

About J2EE MVC architecture and its design pattern is what to share here, I hope the above content can be of some help to everyone, you can learn more knowledge. If you think the article is good, you can share it so that more people can see it.

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.