Only the backend is involved, see the top column for all directories, codes, documents, and interface paths are:
[Lilishop Mall] Record the study notes of the B2B2C mall system~
The whole article will combine the business introduction to focus on the design logic, which includes the interface class and business class, and the specific source code analysis, the source code is not complicated to read~
Caution: Some comments in the source code are wrong, some comments have completely opposite meanings, and some comments are not correct. I updated them during the reading process and added new comments where I did not know. So be careful when reading the source code!
Table of contents
A1. Interface input parameters
C1. Modify full business information
A2. Interface output parameters
A3. Various pojo types (can be skipped)
B1.PO=entity Entity class (must be included)
B2.BO business object (can be omitted)
B4.VO view model object (can be omitted)
This is not mentioned in the previous No4, because the previous focus is on the login logic, which is relatively scattered, so I put it in this article to record the input and output parameters of the interface separately, which will be used in the later product modules. [If there are omissions, the record can be modified at any time later~~~]
There are basically four interfaces: add, delete, modify, and check. We also analyze from these four.
A1. Interface input parameters
B1. New type
Interface input parameters are mainly divided into the following three types:
- Basic business information of basic data types that are not associated with other tables;
- The basic business information associated with other tables can be understood as a foreign key;
- Field for business verification/judgment;
- Basic business information of the reference type (can include the above three types);
1. Basic business information of basic data types that are not associated with other tables;
These attribute fields belong to the basic data types (String, Double, Integer, etc.), and there are corresponding fields in the data table, such as: commodity name, commodity price, etc.;
2. The basic business information associated with other tables can be understood as a foreign key;
These attribute fields are unique identifiers belonging to other tables and can be understood as foreign keys. Most of these attributes are used for fields with separate business tables. Because the foreign key information is mainly stored, most of them are of String type, and collections and arrays can also be used to receive them. For example: product classification, product catalog, etc.;
3. Field for business verification/judgment;
Such attribute fields are not basic business information and will not be stored in the data table. Most of them are fields added to simplify judgment and provide verification. Some are for front-end control passing values, and some are for back-end processing.
4. Basic business information of the reference type;
Put this at the end. First of all, it must be the basic information of the business, that is, the necessary information, which is mainly used for complex data or batch data. It can be expressed directly by using a reference object, or it can be used in combination with a collection (List, Map, etc.). For example: product parameters, product sku information, etc.;
This type can contain the above three types, because it uses the reference object type, so it belongs to the pojo class, so it can combine the above three types~~~
Let's take the product information as an example, the following screenshots illustrate:
For details, see the code of the GoodsStoreController class.
B2. Modification type
There will be a lot of modified interfaces, which are mainly divided into the following two categories;
C1. Modify full business information
This is our common "editing", which is similar to adding a new entry, which is to modify all the information of the business, so I won't repeat it here, refer to A1 .B1 .
C2. Modify some information
As the name implies, this is to modify several items of information, such as modifying the status of the product, only the unique identifier and status value of the product are required, so you can directly pass parameters to specify several fields, and if there are many fields, you can also pass values to reference objects.
For example: GoodsStoreController#freight to modify the freight template, this method is to pass the product id and template id. GoodsStoreController#updateStocks Modify the stock, this method is the data of the reference type passed.
B3. Delete type
This is very simple, you only need to pass the unique identifier of the reference business, the backend can be directly hard deleted, and the backend can also be soft deleted~
For example: GoodsStoreController#deleteGoods Delete goods, this method is to pass the product id and template id.
B4. Find type
For the search type, you can use the reference object type or the parameters, but if the search field conditions can be reused, then we must use the pojo reference object class to receive the parameters.
For example: in the paging search, the page number, page number, etc. are all unified, so they can be reused. The GoodsStoreController#getByPage method input parameter is a reference type, and the reference type inside also inherits the public paging VO~
A2. Interface output parameters
The output parameters are mainly divided into two categories, one is adding, modifying, and deleting, and the other is searching;
B1. Add, modify, delete types
In this category, there are mainly two cases where the operation succeeds and returns success information, and the operation fails and returns an exception. Generally, no data is required, that is, no data is returned, and only code and msg are required.
For example: GoodsStoreController#save method returns ResultUtil.success() successfully, the exception will be intercepted by GlobalControllerExceptionHandler and returns ResultUtil.error(ResultCode.ERROR.code(), errorMsg)
B2. Find type
In this category, there are mainly two cases where the operation succeeds and returns a success message, and the operation fails and an exception is returned. If the operation succeeds, data will be returned, that is, data will be returned, and code and msg will also be returned.
For example: the GoodsStoreController#get method returns ResultUtil.data(goods) successfully, and the operation exception is the same as above
A3. Various pojo types (can be skipped)
For details, you can read this article. It is very detailed and has examples, but it seems a bit of a title party~~~: An article clearly explains the difference between VO, BO, PO, DO, and DTO- Know almost
Summarize according to my understanding
B1.PO=entity Entity class (must be included)
It is the entity class, corresponding to the data table, there is nothing to say
B2.BO business object (can be omitted)
It is an auxiliary data belonging to the back-end business logic. It is added to other data on the basis of PO objects, or combined with multiple PO objects. It will be used for complex businesses, but not for simple ones.
B3.BTO data transfer object
It is usually used for data transmission between the front and back ends, and can be used as request input and output parameters. Its meaning is to be able to fully express a business module, so it is usually used for interface input parameters.
B4.VO view model object (can be omitted)
The data that needs to be displayed is transmitted from the back end to the front end. In the front-end and back-end separation architecture, it is usually json type data. If it is not complicated or the data displayed is not far from the business itself, you can use PO or DTO directly.