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

How to build an appropriate Web framework, in view of this problem, this article introduces the corresponding analysis and answers in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Previously, we built a development framework step by step in the derivation of the Web development framework.

Under the circumstances, the demand was met. However, with the gradual improvement of the project, the frequency of requirements change is gradually higher than that of new requirements, and the disadvantages of the original framework are becoming more and more obvious, so it is necessary to upgrade and improve the framework.

Let's first look at the problems of the original framework, and then improve the framework based on these problems.

The problem of the original framework

Code generation problem

In the original framework, we wrote a code generation component based on various constraints, through which we can generate a series of classes such as Controller,Service,Model,Mapper for the selected table, that is to say, as long as we finish building the table, we can directly generate a set of CRUD, which can be started and tested directly. This looks beautiful at the beginning of the project, but there are still a lot of limitations when requirements change.

First of all, the generated code logic is fixed. If you make some adjustments, you need to adjust the components that generate the code, then repackage it, upload it to the jar repository, modify the component version of the project, and then generate the code, which is too tedious.

Secondly, a lot of compromises have been made to facilitate the generation of code:

To facilitate regeneration after modifying the table field, many classes abstract a base class for manipulating the Model field. These base classes cannot be modified manually because each build is overwritten. This actually leads to an increase in the number of classes.

The generated CRUD is solidified and cannot be adjusted manually. If the generated CRUD does not meet the requirements, it cannot be modified directly in the code. Only one copy can be copied for modification, because it will be overwritten when it is generated again. This leads to code redundancy.

Param and Result delegate Model, which allows you to know the adjustment of the corresponding fields at compile time when the Model changes. However, a lot of problems have been introduced, which we discuss separately in the "Parameter transfer problem" section.

Parameter transfer problem

In order to facilitate code generation, it was decided that both Param and Result inherit Model, which led to the following problems:

Makes both Param and Result dependent on Model. But Param and Result are the view layer model, while Model is the persistence layer model, and their degree of evolution is not the same. But the current inheritance relationship causes the evolution of the view layer model to be synchronized with the persistence layer by default, and of course you can manually adjust Param and Result, but this in turn leads to the loss of the advantages of code generation.

Param and Result set the fields by delegating, that is, they actually have no fields, and the values are set to the Model through getter and setter. This makes it impossible to use lombok to simplify getter and setter, resulting in more lines of Param and Result code

At the same time, for swagger, some annotations need to be field-based, making it impossible to implement some functions (for example, ModelAttribute) and can only be handled based on additional means (for example, field documents need to be implemented through ApiImplicitParams).

CRUD is based on the same Param and Result, which causes the front-end interface to display a lot of useless fields, making it more difficult for the front end to understand the interface.

Service layer problem

The Service layer has the following problems:

The responsibilities of the Service layer are too heavy, including transaction processing, parameter setting, and business logic.

As a result, the code in Service is noodle code, which is not conducive to the understanding of business logic.

At the same time, transaction annotations are directly added to the class, and the default transaction mechanism of Spring will cause logical calls like the following code not to throw the expected exception.

/ / PostService public String savePost (Post post) {postRepository.save (post); for (PostDiscuss discuss: post.getDiscuss ()) {/ / the RuntimeException exception cannot be caught here, and it will be a TransactionRollBack exception discussService.save (discuss);}} / / discussService public String savePost (PostDiscuss discuss) {throw new RuntimeException ("save failed");}

Test dependency problem

The core business logic is in Service, and testing still depends on Spring, and as the project gets bigger, it takes longer to start the project, perhaps a minute or more. This leads to lower and lower efficiency of unit testing.

The problem with Mapper.xml

During the interview, I often ask the following questions:

What is the function of the interface in Java?

Why should Service and DAO write an interface and then implement it?

The interface and implementation are repackaged under the same module anyway. Don't you write several more lines of code to write more than one interface?

Similar to the problem above, Mybatis claims to separate sql into Mapper.xml files, so that sql can be modified directly without compilation. But Mapper.xml is put together with Class, changed or need to be repackaged, and Mybatis can not dynamically load Mapper.xml, so what is the advantage of independent sql into XML?

My answer to the last question is, for most projects, there is no advantage! Whether the project is easy to deploy or expand does not depend on the framework you use, but on your design.

In the case of Mapper.xml, Mybatis separates the sql from the code, but if you still put the Mapper.xml and the code under the same module in the project, this advantage is lost. Since we don't have this advantage, is it necessary for us to write Mapper.xml files separately? My choice is not to write, but to use the annotations provided by Mybatis.

At the same time, in order to solve the strong dependence of the Service layer on the DAO layer (in this case, on the Mybatis), some improvements have been made to the framework to decouple the Service layer and the DAO layer. See the improvement plan below for details.

Framework improvement scheme

In order to solve these problems, the framework has been adjusted as follows:

Separate Param, Result, and Model

Replacement code generation

Independent business logic

Model layer optimization

Separate Param, Result, and Model

It has been mentioned above that there are many problems with the strong coupling of Param, Result, and Model, so here we separate Param, Result, and Model. Each is a separate Bean, which solves the above problems. But two new questions have been introduced:

First of all, it is obvious that the amount of manual coding has been increased. When a table modifies fields, three or more classes need to be modified

Secondly, the code between data transfer is added. That is, Param is passed to Model, and the field needs to be assigned a value. If you set the value of a field, it will add a lot of boring code. Using reflection will have some impact on performance.

So how to solve these two problems? First of all, pure hand masturbation is definitely impossible. Some automation means need to be provided.

For assignment, Spring provides BeanUtils to simplify processing, although it is based on reflection to set the value, but at this stage, this performance loss is not affected. However, BeanUtils cannot copy different types of properties. Suppose I have a Domain object Book with a field Author in it. Now I want to assign a value to BookResult, where there is a field AuthorResult, and BeanUtils cannot be assigned. So I wrote a Gson-based utility class to handle it. It takes more than 500ms to copy BeanUtils for 10000 performance tests, and only about 300ms for Gson-based utility classes.

For table field generation, if IDEA is used, IDE provides a script by default to generate POJO from the table! We can use this script to generate Model and then copy the fields to Param and Result to simplify field writing. I modified the script to meet the requirements of the project. Mainly added lombok support, added class comments and field comments.

Replacement code generation

For the above problem with the code generation component, I adjusted the way the code was generated. It is no longer based on components, but on FileTemplate, LiveTemplate, and Scripted Extensions of IDEA itself. Although it is impossible to generate multiple files at one time in this way, the impact is not great because the generation logic is basically one-time. When code is generated for the first time, the code generation component is more efficient than the combination of FileTemplate, LiveTemplate, and Scripted Extensions, but the flexibility of later adjustment is obviously higher than that of the code generation component with the combination of FileTemplate, LiveTemplate, and Scripted Extensions:

First of all, when the file is restructured, you only need to modify the FileTemplate and export the configuration file to the project team members.

Similarly, when the LiveTemplate is adjusted, you only need to modify the corresponding LiveTemplate and export the configuration file to the project team members.

Second, which file you want to generate, just generate it for that file.

Third, after the complete file is generated through FileTemplate, you can quickly carry out modular coding through LiveTemplate.

Finally, FileTemplate can be set to the project level, that is, each project can have a separate FileTemplate

The specific operation flow is demonstrated below.

Independent business logic

To solve the problem of Service and testing, the original Controller, Service and Model layers are divided into four layers:

Controller is responsible for receiving and returning front-end data, as well as unified exception handling.

Service is responsible for the assembly of transactions and Domain layer logic. The problem of transaction nesting will not occur here, and it will not lead to the problem of missing the expected exception.

Domain is responsible for business logic

Model is responsible for data persistence

In this way, the responsibility of Service is reduced, and there is no problem of transaction nesting.

Model layer optimization

As mentioned above, the framework eventually abandoned Mapper.xml in favor of using Mybatis annotations for persistence operations. Using annotations instead avoids the writing of XML code, but does not solve the framework's strong dependence on Mybatis. Therefore, a new Repository interface layer is added to Domain, which is used to define the persistence operation of Domain, while Repository is implemented in the Model layer, which is the Mybatis implementation. This has two benefits:

Dependency inversion: instead of Domain relying on the Model layer, now the Model layer relies on the Domain layer, so that when I replace Mybatis, Domain is completely unaware.

Independent testing: because Domain now does not depend on any other layer, it can be tested separately from the database and container. So that the efficiency of testing will not become lower and lower with the development of the project.

Details of framework improvement

Now that we know how to improve the framework, we begin to transform it now. In fact, the main transformation is the transformation of the way of code generation, that is, writing FileTemplate, LiveTemplate and ScriptedExtensions. The following is a brief description of these three functions, starting with ScriptedExtensions.

Scripted Extensions

Let's first explain what Scripted Extensions is. As we all know, today's IDE is plug-in, that is, we can develop plug-ins and extend existing IDE functions through the plug-in development kit provided by the developer. However, writing plug-ins requires a specific development environment, and if it is a very simple function, it is troublesome to build a development environment. So IDEA provides Scripted Extensions, which can be understood as a simplified version of the plug-in, that is, you can extend IDE functionality through scripting.

IDEA provides the Database function, which can connect to the database for related operations. When you connect to the database and right-click on the table, you can see the option Scripted Extensions, which has a function to generate groovy scripts for POJO based on the table.

But the function compares low:

The package name is written dead: com.sample

No table comments were generated

No lombok-based simplification of getter and setter

Fortunately, we can modify the line based on this script. In the Scripted Extensions menu, there is a Go to Scripts Directory option. After clicking, you can go to the script directory.

Directly to the groovy file Ctrl+c,Ctrl-v, make a copy, rename it, and modify it based on this script. Specific how to modify, according to their own needs, which is mainly based on the table information of the String splicing.

FileTemplate

FileTemplate is a template for generating files provided by IDEA. You can click File- > New... on the menu. In the future, all kinds of files are based on FileTemplate. Our custom Controller, Service, Domain and other classes can be created easily through FileTemplate.

To use it, press the Ctrl-Alt-S outbound settings menu, click Editor- > File And Code Template, and add Template to it.

The following points are explained:

Some of the default parameters and roles are listed in the following description

You can also customize the variable. if the custom variable is not assigned, there will be an input box to prompt for input when you create it.

Templates are based on Velocity, so if you are familiar with Velocity, you can use them directly.

The Enable LiveTemplate option activates the LiveTemplate variable in FileTemplate, but requires a # [[]] # package. However, for the creation of Java, this feature has bug, which cannot be located in the desired location, so it is not used for the time being.

After the creation is complete, you can see the template in the New menu.

LiveTemplate

LiveTemplate is actually CodeSnippet. It is created in a similar way to FileTemplate. Press the Ctrl-Alt-S outbound settings menu, click Editor- > Live Template, and add Template to it.

The following points are explained:

The variable here is to use $$package

Each variable is a placeholder, and after expanding with tab, you can enter the value manually

The Edit variables in the lower right corner is used to assign values to variables. IDEA provides some methods, or you can set default values.

In the following change link, you can choose the location where the LiveTemplate takes effect, for example, only where the Java class declaration takes effect

Coding flow

After creating the above templates, the coding process is as follows:

Right-click on the table to generate Model through Scripted Extensions

Quickly generate Controller, Service, Domain and other classes through FileTemplate

Write code quickly through LiveTemplate

This is the answer to the question on how to build a suitable Web framework. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about 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.