CN114385145A - Web system back-end architecture design method and computer equipment - Google Patents

Abstract

The invention discloses a Web system back-end architecture design method and computer equipment. The method comprises the following steps: establishing a basic hierarchical structure of a Web framework, wherein the basic hierarchical structure comprises: an app control layer, bll business logic layer and dal data access layer; defining an entity class package; defining a configuration class package; defining a tool class package; defining a resource file; defining a code generation specification; defining classes and inheritance of classes; a call relationship is defined. The technical scheme provided by the embodiment of the invention provides a set of Web backend architecture with complete functions, small size and flexibility, and after the design of the database is finished, a new project with high availability can be quickly generated through a code template on the basis of the architecture design, so that the problem of repeatedly creating wheels in the traditional information system is avoided.

Description

Web system back-end architecture design method and computer equipment

Technical Field

The embodiment of the invention belongs to the technical field of computers, and particularly relates to a method for designing a rear-end architecture of a Web system and computer equipment.

Background

With the rapid development of internet technology, a Web system with separated front and back ends is gradually widely adopted in the industry. One of the purposes of separating the front end from the back end is to achieve specialized division of labor, improve the quality and the development efficiency of a project and reduce the tolerance of the front end to the back end.

In the current development process of Web backend projects, developers usually rely heavily on their own programming capability to implement project functions, and need to spend a lot of time, that is, "repetitive wheeling" is often said in the computer industry. Even if a programmer wants to reference a packaged component to others in a community of published documents, the process of finding a wheel is not trivial; a wheel is not easy to find, and the usage can not be learned; the writing wheel is not easy to operate, is inconsistent with requirements in many places, cannot be changed, and finally is changed into the writing wheel.

The best embodiment of this situation is the PHP framework that once opened throughout a period of time. Every person writing the frame thinks that the frame written by himself is the best wheel, and even many new PHP people, after a few mature frames have a lot of years, have a lot of investments in writing the lines and rows of the frames. Most finished products are different from each other in size, only the grammatical level is more consistent with the habits of the authors, a large number of tests and document communities are lacked, and the final result is a semi-finished product and then a non-rapid product.

The prior art needs to provide a set of reasonable front-end and back-end separation architecture, help programmers to generate new projects quickly on the basis of architecture design, and avoid the problem of repeatedly creating wheels in the traditional information system.

Disclosure of Invention

The embodiment of the invention provides a method for designing a Web system back-end architecture and computer equipment, which are used for realizing the rapid generation of a new project at the back end of a Web system.

In a first aspect, an embodiment of the present invention provides a method for designing a backend architecture of a Web system, where the method includes:

establishing a basic hierarchical structure of a Web framework, wherein the basic hierarchical structure comprises: an app control layer, bll business logic layer and dal data access layer; the app layer is used for providing interface service for the outside, interacting with a front end or a third party, receiving the incoming parameters and returning an operation result; the bll layer is used for controlling business logic, adding, deleting, modifying and checking detailed records of action logs; the dal layer is used for database access;

defining an entity class package comprising: querying a parameter entity and a data access entity;

defining a configuration class package comprising: configuration items, global exceptions, filters, interceptors, notes, enumerations and configurations of the SpringBoot;

defining a toolkit comprising: the system comprises a user-defined tool class, a snowflake algorithm generator and a date-time format converter;

defining a resource file, wherein the resource file is used for placing a mapping file of a dal layer and a configuration file of a program;

defining a code generation specification, comprising: dividing codes completely generated by the template, codes partially generated by the code template and all handwritten codes into different packages for storage; wherein the code generated entirely by the code template prohibits modification, the code generated partially by the code template is generated only once, and subsequent modification is permitted;

defining classes and inheritance of classes, including: the class in the package for generating the code inherits the top level parent class, and the code generated only once inherits the class in the package for generating the code;

defining a calling relationship, including: when a class in the bll packet calls a class in the bll packet, and/or a class in the bll packet calls a class in the dal packet, classes in the split packet can only call classes in the split packet, and classes in the unity packet can only call classes in the unity packet.

In a second aspect, an embodiment of the present invention further provides a computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, where the processor, when executing the program, implements the method for designing a backend architecture of a Web system according to any one of the embodiments of the present invention.

The embodiment of the invention establishes a basic hierarchical structure of a Web framework, wherein the basic hierarchical structure comprises the following steps: an app control layer, bll business logic layer and dal data access layer; defining an entity class package; defining a configuration class package; defining a tool class package; defining a resource file; defining a code generation specification; defining classes and inheritance of classes; a call relationship is defined. After the design of the database is finished, a new project with high availability can be quickly generated through a code template on the basis of the design of the architecture, and the problem of repeatedly creating wheels in the traditional information system is solved.

Drawings

Fig. 1 is a flowchart of a method for designing a backend architecture of a Web system according to an embodiment of the present invention;

fig. 2 is a flowchart of a method for designing a backend architecture of a Web system according to a second embodiment of the present invention;

fig. 3 is a schematic structural diagram of a computer device according to a third embodiment of the present invention.

Detailed Description

The embodiments of the present invention will be described in further detail with reference to the drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of and not restrictive on the broad invention. It should be further noted that, for convenience of description, only some structures, not all structures, relating to the embodiments of the present invention are shown in the drawings.

Example one

Fig. 1 is a flowchart of a method for designing a backend architecture of a Web system according to an embodiment of the present invention, and is applicable to a development process of a Web backend project. In a specific development work of a Web backend project, a developer firstly formulates a Web system backend architecture according to the method provided by the embodiment of the invention, and then puts general codes which need to be written by hand into the architecture. And then configuring a code template, specifically comprising configuring a database, configuring a project name and configuring a generation folder (namely, configuring a position of a code to be generated), wherein the generation folder is generated according to an item directory specified in the architecture, and finally clicking to generate. If the database table structure is updated, the code template is only needed to be reconfigured, and the (pure-generated) affected code is regenerated.

The method for designing the rear-end architecture of the Web system specifically comprises the following steps:

s101, establishing a basic hierarchical structure of a Web framework, wherein the basic hierarchical structure comprises: an app control layer, bll business logic layer and dal data access layer; the app layer is used for providing interface service for the outside, interacting with a front end or a third party, receiving the incoming parameters and returning an operation result; the bll layer is used for controlling business logic, adding, deleting, modifying and checking detailed records of action logs; the dal layer is used for database access;

the Web application framework (Web application framework) is a development framework, and is used for supporting development of dynamic websites, Web applications and Web services. There are two types of frameworks, request-based and component-based. The embodiment of the invention adopts a general three-layer architecture, namely a control layer (app), a business logic layer (bll) and a data access layer (dal), adopts SpringBoot as a main frame, and adopts MyBatis as a data access layer frame. Most of the classes in the three-tier architecture can be generated from database tables.

S102, defining an entity class package, comprising: querying a parameter entity and a data access entity;

the entities in the entity class package (ent) are in one-to-one correspondence with the tables in the database, for example, the user table is used in the database, and the corresponding ent will have the generation class and the inherited extended class of the user table (user), and the parameter class (parameter for referencing during query).

S103, defining a configuration class package, comprising: configuration items, global exceptions, filters, interceptors, notes, enumerations and configurations of the SpringBoot;

wherein the files in the configuration package are used for providing corresponding functions. The classes in each function package inherit from the classes in the configuration class package.

S104, defining a tool package, comprising: the system comprises a user-defined tool class, a snowflake algorithm generator and a date-time format converter;

wherein, the files in the tool kit are used for providing tool classes commonly used in JAVA development.

S105, defining a resource file, wherein the resource file is used for placing a mapping file of a data access layer and a configuration file of a program;

s106, defining code generation specifications, including: dividing codes completely generated by the template, codes partially generated by the code template and all handwritten codes into different packages for storage; wherein the code generated entirely by the code template prohibits modification, the code generated partially by the code template is generated only once, and subsequent modification is permitted;

the embodiment of the invention extracts a plurality of universal codes in the architecture design, can be made into a code template by using tools such as CodeSmith and the like, and then generates the code template in batches. So the code in the whole project can be roughly divided into three categories: the first type is fully handwritten code, such as in a configuration class package (set), a tool class package (utl); the second type is code generated entirely by the template, such as in the generate package, where the code in the package prohibits human modification; the third type is partly code generated by a code template, such as in split packages, where the code is generated only once and can be subsequently modified manually based on this generation.

S107, defining the class and the inheritance of the class, including: the class in the package for generating the code inherits the top level parent class, and the code generated only once inherits the class in the package for generating the code;

the inheritance relationship corresponds to a hierarchy in the item directory structure and is used for indicating the inheritance relationship of different packages in the same layer of the whole back end. Typically there is only one top parent class in each layer, and a class in a package that generates code will inherit to a top parent class, and code that is generated only once will inherit to a class in a package that generates code.

S108, defining a calling relation, comprising: when a class in the bll packet calls a class in the bll packet, and/or a class in the bll packet calls a class in the dal packet, classes in the split packet can only call classes in the split packet, and classes in the unity packet can only call classes in the unity packet.

According to the technical scheme of the embodiment, a basic hierarchical structure of a Web framework is established, and the basic hierarchical structure comprises the following steps: an app control layer, bll business logic layer and dal data access layer; defining an entity class package; defining a configuration class package; defining a tool class package; defining a resource file; defining a code generation specification; defining classes and inheritance of classes; a call relationship is defined. After the design of the database is finished, a new project with high availability can be quickly generated through a code template on the basis of the design of the architecture, and the problem of repeatedly creating wheels in the traditional information system is solved.

On the basis of the above technical solution, the defining the code generation specification further includes:

defining classes under the extended package to allow manual change;

defining the class under the generate packet not to allow manual change;

except for the code which is purely handwritten, the class under the definition unit package does not allow manual change;

defining classes under the split package to allow manual alteration in addition to code generated entirely by the template;

except for the base package and the custom package, classes and files under the definition app, bll, dal, ent and xml packages are all generated by using code templates according to data model entities.

It should be noted that, since the second type of code is continuously updated throughout the development process, the code is divided into different packages in order to distinguish the generated code from the handwritten code and prevent the handwritten code from being overwritten. Developers should follow the following rules to ensure the security and normalization of code:

1. all the extension packages can be manually changed.

2. The classes under the generate package cannot be changed manually.

None of the units under the Unit Package can be changed manually, including mapping files. Except for case 1.

All under the split package can be changed manually, including mapping files. Except for case 2.

Classes and files under app, bll, dal, ent and xml are all generated according to data model entities by using code templates, except the following cases:

base packages are all parent classes and can be manually changed, but the change can affect all child classes.

And 2.custom classes are arranged under the custom packet and are not controlled by the code template.

On the basis of the above technical solution, the defining the code generation specification further includes:

defining a dal packet and an xml packet, wherein classes are not allowed to be added without consent of architects;

defining a new package or class in the first layer of app, bll, ent, config, which is not allowed to be created by architect, and placing the new package in the second layer into a custom package;

classes in the definition config package and utl package are not allowed to be modified without the consent of the architect.

It should be noted that the following rules should be followed for manually adding a class or a package:

1. newly added classes are strictly prohibited in dal, xml packages without the consent of the architect.

2. Without the consent of architects, no new package or class is allowed in layer 1 of app, bll, ent, config, and the new package in layer two is to be placed in custom (there is no new creation of custom).

3. Classes in the config and utl packages cannot be modified without the consent of the architect.

The split packet under the general packet is not expanded at different times in the same project, because the split packet under the dal layer cannot be generated again after the initial code generation. This is to accumulate the extensions in different projects, for example, when it is found that some unity is not good to implement in the later period.

By establishing a basic hierarchical structure of a Web framework and defining a strict code generation specification, the technical scheme of the embodiment can reduce the problems of calling errors and the like of items generated according to the framework in the use process. The condition that the whole project is unavailable due to design errors of developers is avoided.

Example two

Fig. 2 is a flowchart of a method for designing a backend architecture of a Web system according to a second embodiment of the present invention, where this embodiment performs optimization based on the above-described embodiment, as shown in fig. 2, the method according to the second embodiment of the present invention further adds definitions of specific functions in the Web architecture, and the method includes:

s201, establishing a basic hierarchical structure of a Web framework, wherein the basic hierarchical structure comprises: an app control layer, bll business logic layer and dal data access layer; the app layer is used for providing interface service for the outside, interacting with a front end or a third party, receiving the incoming parameters and returning an operation result; the bll layer is used for controlling business logic, adding, deleting, modifying and checking detailed records of action logs; the dal layer is used for database access;

s202, defining an entity class package, comprising: querying a parameter entity and a data access entity;

s203, defining a configuration class package, comprising: configuration items, global exceptions, filters, interceptors, notes, enumerations and configurations of the SpringBoot;

s204, defining a tool package, comprising: the system comprises a user-defined tool class, a snowflake algorithm generator and a date-time format converter;

s205, defining a resource file, wherein the resource file is used for placing a mapping file of a data access layer and a configuration file of a program;

s206, defining code generation specifications, including: dividing codes completely generated by the template, codes partially generated by the code template and all handwritten codes into different packages for storage; wherein the code generated entirely by the code template prohibits modification, the code generated partially by the code template is generated only once, and subsequent modification is permitted;

s207, defining classes and inheritance of the classes, wherein the definition comprises the following steps: the class in the package for generating the code inherits the top level parent class, and the code generated only once inherits the class in the package for generating the code;

s208, defining a calling relation, including: when a class in the bll packet calls a class in the bll packet, and/or a class in the bll packet calls a class in the dal packet, classes in the split packet can only call classes in the split packet, and classes in the unity packet can only call classes in the unity packet.

S209, defining transaction control, including: support for transactions is added in the top level parent classes at the app and bll levels.

Because support for transactions is added in the top parent class of the app and bll layers, the development only needs to inherit the parts of the two classes, and if no special condition exists, separate transaction processing is not needed.

S210, defining constraint control, wherein the deleting action during the constraint of the foreign key is configured into cascade processing, and the updating action is configured not to be processed in cascade.

In practical development, it is found that it is very difficult and cumbersome to control cascade deletion only by a program because there are many problems of deletion delivery. For example, deleting the application domain GpDomain, the page deleting component GpControl is cascaded, the page deleting component gpcrontrol is cascaded to delete the role component GprRoleControl, and the like, and the code generation is uncontrollable after the first-level transfer.

If the foreign key constraints are all uniformly configured as result, the logic for writing the Cascade delete in the program is not feasible, and because the Cascade delete cannot be deleted if the records exist in the sublist, the Cascade delete should be set as Cascade processing Cascade.

In rigorous engineering development, foreign key constraints should be necessary. Unless logical deletion is used, physical cascade deletion should be given to the control of the database, and the logical integrity and validity of the data can not be fundamentally ensured. However, whether program control or database control is selected, whether Cascade or SetNull, the final delete action is determined by the actual business.

And when cascade update is carried out, the condition that the non-primary key is the foreign key does not exist in the current data model, so that the cascade update is directly set in the database without cascade processing NoAction.

S211, defining exception handling, comprising:

bll, encapsulating the captured operation exception into a self-defined global exception throwing in each method, and recording a log in a final block;

registering a global exception handler in the set packet;

the global exception handler is used for capturing all application exceptions, converting the exceptions into an agreed format and returning the agreed format to the front end.

Wherein, the bll layer captures the operation exception in each method, and then encapsulates the operation exception into a self-defined global exception GlobalException to be thrown out, and records the log in final. And then, registering a global GlobalExceptionHandler in the set packet by using @ controllerAddress to capture all application exceptions, processing the captured exceptions, converting the exceptions into an agreed format, and returning the agreed format to the front end, wherein the state code at this time is 500HttpStatus.

Therefore, if no special condition exists, the front end does not need to judge whether the operation is successful in the Success methods of a plurality of ajax, and other interactive logics are directly processed, because the error method is used if the back end has an exception.

In the current bll layer, the operation execution is considered to be successful when the dal layer method can be normally executed and no exception is reported. Or, without special case, the success method using ajax defaults to a successful operation.

For example, a certain record is requested to be deleted, but the record is deleted by other requests, and the execution of the deletion action is actually deleting 0 records; for another example, 5 records are modified in batch, 2 records do not exist, and 3 records are actually modified; when the query is made, 0 piece of data meeting the query condition is queried, and the programs return success.

During writing operation, the specific incoming number and the number of successful actual operation are recorded in the log, and different prompts are returned according to whether the number is the same or not.

S212, defining dictionary analysis, comprising:

adding a custom annotation and a custom JSON parser for performing dictionary coding parsing to process dictionary items returned to the front-end JSON data;

or, when the bll layer returns a packaged result ResultModel object with a uniform type, and the content of the ResultModel object is List < map >, writing a tool class for performing dictionary coding resolution.

For the resolution of dictionary entries, two sets of methods are provided in the current architecture.

The first method is to add a custom annotation dictionary convertantiondictionary convertert and a custom JSON parser Jacksondictionary serrializer to realize the function of dictionary code parsing so as to process dictionary items returned to the front-end JSON data. The specific calling method is to add the following comments in the entity class attributes:

@DictionaryConvertAnnotation(typeId＝"dc1f9015660bcbcee7f1dfc1a5dea1ea",codeField＝"isMarriageCode")

@JsonSerialize(using＝JacksonDictionarySerializer.class,nullsUsing＝JacksonDictionarySerializer.class)

private String isMarriageValue；

second, when the bll layer returns a ResultModel object and the data contains List < map >, a tool class dictionary is written and analyzed by the tool class. The specific calling mode is that returned data and the entity object to be converted are transmitted into: -mapresiltmodel resultModel ═ gpuserusltbll.

resultModel.setData(DictionaryConvertUtil.convertMapListToTextList(GpUser.class,resultModel.getData()))；

S212, defining a return format, including:

unifying method returns in an bll layer and method returns in an app layer into a ResultModel object, wherein the ResultModel inherits a log class entity;

returning the operation log to an app layer while writing the operation log to a database at bll layer;

the app layer processes the operation log and returns the operation log to the front end;

and processing the returned result in the ResultModel class, wherein the processing comprises the following steps: the results returned to the front end are filtered using JSON annotations and/or boolean fields are added to distinguish whether the operation was successful.

Wherein the operation log contains the operation result.

S213, defining list sorting, comprising:

setting an alias for each column involved in SQL; providing a query interface for displaying the list;

the front end displays according to the list names, and transmits the list names to the back end as parameters, and the sequencing is controlled by a program of the back end.

In daily product design, it is often required that all columns present in the list presentation can be sorted. Therefore, in the architecture, all columns involved in SQL are aliased. If two table join queries are involved without aliasing, then the aliasing of the tables must be introduced, otherwise errors such as Column 'update _ time' in order close is ambiguous may occur. The introduction of table aliases is not beneficial to the front-end and back-end unified control.

The method for designing the rear-end architecture of the Web system provided by the embodiment of the invention can also comprise the following steps:

defining a caching process comprising:

if the current program does not integrate Redis, a self-contained caching mechanism of the SpringBoot is used.

The method for designing the rear-end architecture of the Web system provided by the embodiment of the invention can also comprise the following steps:

if there are a large number of designs in the business that cannot be easily written once initialized, such as Web exposure with application configuration, service interfaces, static links, system components, dictionary design, backend programs with enumerations, constants, etc. Modifications to these parts, additions and deletions, are often accompanied by program changes. For the enumeration part, the semantics of java enumeration of the data structure type is static, fixed and difficultly-modified data, and the readability of the code is damaged by dynamically loading an enumeration item. For the dictionary part, the dictionary data can in principle not be pruned, but only be added, since the previous dictionary entries have already been used in the history data. The addition of application configurations, service interfaces, static links, system components, data dictionaries, enumerations, constants, must be accompanied by program changes. Note that the data dictionary and the dictionary data above are two concepts, and here, which data dictionary categories are, and the above refers to data items included in a data dictionary of a specific category.

In the method for designing the architecture of the back end of the Web system provided by the embodiment of the invention, the common verification mainly comprises the following conditions: whether the required data is empty, whether the numerical value type is correct, whether the length is correct, whether the data is only repeated, special format identification numbers, mobile phone numbers, mailboxes, link addresses and the like.

The back end temporarily has no simple and efficient method to check the received parameters one by one and uniformly, and if the input is not in compliance, an exception occurs when the write is submitted to the database. We capture and uniformly process these exceptions and then return them to the front end. If the management function of the metadata is added, the specific field check failure can be located, and a relatively friendly prompt is given.

In the method for designing the rear-end architecture of the Web system provided by the embodiment of the invention, the current architecture has universal methods for batch addition and batch modification, and in the methods, whether a certain attribute value is NULL or not is not judged, and the attribute value is directly written.

In the dragging function of the tree structure, after dragging the child node to the root node, the background (updateListWithDff method) cannot modify the farmerId to null. This is a problem with generic code templates and architectures that has existed before, that is, when a user wants to modify a field to a null value, current programs would consider the client not to modify the field.

The method for designing the Web system rear-end architecture provided by the embodiment of the invention adopts the following 4 methods:

1. special places write special sql without handling in a general way. But this approach may appear to be too inflexible and redundant.

2. Before each updating operation, the original data is searched out from the database, the fields needing to be changed are assigned again, and then the updating operation of the whole fields is carried out (no judgment is needed), so that the performance of the method is slightly lower.

3. The service layer judges whether the front-end parameter is null, if so, a special value (such as-1) is assigned for replacement, and then the updating can be successful when the front-end parameter is null. But this is easily understandable and may be less accurate if a recording modification operation is required. The logic is to create an enumeration and set a coding rule, if the value is assigned to NULL, the coding is-1; if the assignment is null character string, the code is-2, and so on. And meanwhile, in a service layer, judging a specific parameter which is allowed to be assigned as a NULL or a NULL character string, and if the parameter is the NULL or the NULL character string, assigning the parameter as-1 or-2.

4. Parameter passing using map, then write: < if test >. Thus, even if the new parameter is NULL, the update can be successful as long as there is the key in the map. But when the entity is used for transmitting the parameter, the function can not be realized.

The technical scheme of the embodiment provides a set of Web backend architecture with complete functions, small size and flexibility, and defines implementation methods of various specific functions. After the design of the database is finished, on the basis of architecture design, a new project with high availability can be quickly generated through the code template, and the problem that a wheel is repeatedly created in a traditional information system is solved.

EXAMPLE III

The embodiment provides a computer device which can be used in the case of Web system backend architecture design. Fig. 3 is a schematic structural diagram of a computer device according to a third embodiment of the present invention. Referring to fig. 3, the computer apparatus includes:

one or more processors 310;

a memory 320 for storing one or more programs;

when executed by the one or more processors 310, the one or more programs cause the one or more processors 310 to implement the method for designing the backend architecture of the Web system as set forth in one or both of the embodiments.

In FIG. 3, a processor 310 is illustrated as an example; the processor 310 and the memory 320 may be connected by a bus or other means, such as the bus connection shown in FIG. 3.

The memory 320 is a computer-readable storage medium and can be used for storing software programs, computer-executable programs, and modules, such as program instructions/modules corresponding to the Web system backend architecture design method in the embodiment of the present invention. The processor 310 executes various functional applications and data processing of the terminal by running software programs, instructions and modules stored in the memory 320, that is, the above-described Web system backend architecture design method is implemented.

The memory 320 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application program required for at least one function; the storage data area may store data created according to the use of the terminal, and the like. Further, the memory 320 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some examples, the memory 320 may further include memory located remotely from the processor 310, which may be connected to the terminal over a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The computer device provided by the present embodiment and the method for designing the Web system backend architecture provided by the above embodiment belong to the same inventive concept, and the technical details that are not described in detail in the present embodiment can be referred to in the first embodiment or the second embodiment, and the present embodiment and the first embodiment or the second embodiment have the same beneficial effects.

It should be noted that the foregoing is only a preferred embodiment of the present invention and the technical principles applied. Those skilled in the art will appreciate that the embodiments of the present invention are not limited to the specific embodiments described herein, and that various obvious changes, adaptations, and substitutions are possible, without departing from the scope of the embodiments of the present invention. Therefore, although the embodiments of the present invention have been described in more detail through the above embodiments, the embodiments of the present invention are not limited to the above embodiments, and many other equivalent embodiments may be included without departing from the concept of the embodiments of the present invention, and the scope of the embodiments of the present invention is determined by the scope of the appended claims.

Claims (10)

1. A method for designing a Web system backend architecture is characterized by comprising the following steps:

establishing a basic hierarchical structure of a Web framework, wherein the basic hierarchical structure comprises: an app control layer, bll business logic layer and dal data access layer; the app layer is used for providing interface service for the outside, interacting with a front end or a third party, receiving the incoming parameters and returning an operation result; the bll layer is used for controlling business logic, adding, deleting, modifying and checking detailed records of action logs; the dal layer is used for database access;

defining an entity class package comprising: querying a parameter entity and a data access entity;

defining a configuration class package comprising: configuration items, global exceptions, filters, interceptors, notes, enumerations and configurations of the SpringBoot;

defining a toolkit comprising: the system comprises a user-defined tool class, a snowflake algorithm generator and a date-time format converter;

defining a resource file, wherein the resource file is used for placing a mapping file of a dal layer and a configuration file of a program;

defining a code generation specification, comprising: dividing codes completely generated by the template, codes partially generated by the code template and all handwritten codes into different packages for storage; wherein the code generated entirely by the code template prohibits modification, the code generated partially by the code template is generated only once, and subsequent modification is permitted;

defining classes and inheritance of classes, including: the class in the package for generating the code inherits the top level parent class, and the code generated only once inherits the class in the package for generating the code;

defining a calling relationship, including: when a class in the bll packet calls a class in the bll packet, and/or a class in the bll packet calls a class in the dal packet, classes in the split packet can only call classes in the split packet, and classes in the unity packet can only call classes in the unity packet.

2. The method of claim 1, wherein defining the code generation specification further comprises:

defining classes under the extended package to allow manual change;

defining the class under the generate packet not to allow manual change;

except for the code which is purely handwritten, the class under the definition unit package does not allow manual change;

defining classes under the split package to allow manual alteration in addition to code generated entirely by the template;

except for the base package and the custom package, classes and files under the definition app, bll, dal, ent and xml packages are all generated by using code templates according to data model entities.

3. The method of claim 2, wherein defining the code generation specification further comprises:

defining a dal packet and an xml packet, wherein classes are not allowed to be added without consent of architects;

defining a new package or class in the first layer of app, bll, ent, config, which is not allowed to be created by architect, and placing the new package in the second layer into a custom package;

classes in the definition config package and utl package are not allowed to be modified without the consent of the architect.

4. The method of claim 1, further comprising:

defining transaction controls, including: support for transactions is added in the top level parent classes at the app and bll levels.

5. The method of claim 1, further comprising:

and defining constraint control, namely configuring the deleting action during the constraint of the foreign key into cascade processing and configuring the updating action not to carry out the cascade processing.

6. The method of claim 1, further comprising:

defining exception handling including:

bll, encapsulating the captured operation exception into a self-defined global exception throwing in each method, and recording a log in a final block;

registering a global exception handler in the set packet;

the global exception handler is used for capturing all application exceptions, converting the exceptions into an agreed format and returning the agreed format to the front end.

7. The method of claim 1, further comprising:

defining a dictionary resolution comprising:

adding a custom annotation and a custom JSON parser for performing dictionary coding parsing to process dictionary items returned to the front-end JSON data;

or, when the bll layer returns a packaged result ResultModel object with a uniform type, and the content of the ResultModel object is List < map >, writing a tool class for performing dictionary coding resolution.

8. The method of claim 1, further comprising:

defining a return format comprising:

unifying method returns in an bll layer and method returns in an app layer into a ResultModel object, wherein the ResultModel inherits a log class entity;

returning the operation log to an app layer while writing the operation log to a database at bll layer;

the app layer processes the operation log and returns the operation log to the front end;

and processing the returned result in the ResultModel class, wherein the processing comprises the following steps: the results returned to the front end are filtered using JSON annotations and/or boolean fields are added to distinguish whether the operation was successful.

9. The method of claim 1, further comprising:

defining a list ordering comprising:

setting an alias for each column involved in SQL; providing a query interface for displaying the list;

the front end displays according to the list names, and transmits the list names to the back end as parameters, and the sequencing is controlled by a program of the back end.

10. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor implements the Web system backend architecture design method according to any one of claims 1 to 9 when executing the program.

Images