I finally did the first task today, the first instance after learning the API. Sales setup development API.
First, the hierarchical structure
1. API layers
The project structure mainly has five layers, namely API, BizModel, Data, DBModel, and Logic.
2. The role of each layer
First of all, for the microservice architecture, the front-end and back-end are separated, the back-end provides data support, and the front-end UI obtains data through API.
The API receives parameters for the controller. The controller layer does not do any logic processing, but only receives parameters through the Model and calls Logic for logic processing.
BizModel is the entity data model corresponding to the front-end UI. We all know that DBModel is an entity data model corresponding to database fields, and BizModel corresponds to UI controls. For example: a User contains fields such as ID, username, password, email, etc., and the front-end control may not only fill in the fields corresponding to the User, but also fill in the information of this User's classmates and family members, so the DBModel cannot correspond. So BizModel transmits data for the front end, which can correspond to fields in multiple DBModels. BizModel is divided into DBModel by Logic and then performs SQL actions.
The Data layer performs database read and write operations.
DBModel is an entity data model.
Logic is the logic layer, separates the BizModel into DBModel, and calls the Data layer to perform read and write actions.
Second, API construction
1. Build a DBModel corresponding to the data table fields
View the data table that needs to be operated, and write the corresponding field
public class PreferenceModel
{
public Guid AdminUserKey { get; set; }
public string MsCCode { get; set; }
public int ShippingAddressSource { get; set; }
public bool Audit1 { get; set; }
public bool Audit2 { get; set; }
public int AutoFeedBack { get; set; }
public int eBayMsgSHowlines { get; set; }
public bool DirectSalesAudit1 { get; set; }
public bool DirectSalesAudit2 { get; set; }
public bool NewTemplate { get; set; }
}
2. Build BizModel corresponding to UI parameters
public class PreferenceEntity
{
public Guid AdminUserKey { get; set; }
public string MsCCode { get; set; }
public int? ShippingAddressSource { get; set; }
public bool? Audit1 { get; set; }
public bool? Audit2 { get; set; }
public int? AutoFeedBack { get; set; }
public int? eBayMsgSHowlines { get; set; }
public bool? DirectSalesAudit1 { get; set; }
public bool? DirectSalesAudit2 { get; set; }
public bool? NewTemplate { get; set; }
}
3. Data layer database read and write methods
I will not show it in detail here, you can handle it yourself.
4. The Logic layer processes the logic and calls the Data layer methods to perform actions
Let's talk about the update logic here. The sales settings in the project are divided into two pages and three update actions, corresponding to the same data table. So the logic is not very complicated, but if you want to update different data without affecting other data, only one API needs to be processed.
Originally, my idea was to update the three methods of the Data layer separately and distinguish them at the Logic layer. This method is not impossible, but based on the principle of simple and easy maintenance, only one method is used to update, and the logic layer handles it. So the idea is that the controller receives the parameters to call Logic, passes the parameters to Logic through Entity, and then judges in Logic that if the parameter of a field does not pass a new value, it will use the original data value to update. The idea is correct, and the next step is to implement it.
When encountering a problem, the int and bool type fields cannot be judged to be non-null, so I don't know whether the default 0 of the int type and the default false of the bool type are the passed values.
Solution: Define bool and int as bool? and int? in BizModel, and use stealth to judge whether the variable is empty. If it is not empty, then force the parameter to update the data.
5.Controller definition
The API has only GET, PUT, POST, and DELETE methods. In order to be standardized, the Controller naming must be standardized. Controller receives parameters and calls Logic to return data.
At this point, the main build of the API has been completed. Next, Build checks to see if there are any errors, try running without errors, and enter the Swagger test.
After the test is successful, it will be released, and the release will be tested using Postman.