As we continue our lesson, recall that in the previous section, we did the most important thing, which was to get through the database read and connection, which laid a solid foundation for the actual combat below and later, and future work and ideas It's nothing more than a multi-table joint search and improved server performance! There is nothing more than the second quarter.
Let's continue our content and standardize the return data of the interface. Anyone who has done the front end knows that the interface returns must have a business logic state, jump to different pages according to different states, and do different logical actions. Therefore, this business logic state is still important at this time. Note that this is the business logic state, not the state of HTTP connection. The state of HTTP, we do n’t need to care at all, and the server does not have to return the state of HTTP. The class responsible for communication between the client and the server has this state. The server It would be too unprofessional to return again.
Any interface should return the three common attributes of int status , object data , and string msg . The front end does different business logic based on the status value. Msg is used in some cases to directly display the text returned by the interface for prompting without writing to the front end. Therefore, it is necessary to define a class, the return of all interfaces must be this class.
Right click on the Models folder of the project, add- > class and name it ApiModel
We add the following field attributes for this class, as you can see, I started to add simple and necessary comments to the code. This is a good habit. When writing code in the future, you need to add comments, which is conducive to your business processing and Understanding of the code.
The interface returns JSON data. In fact, there are corresponding classes in itself. Let's transform it and see the result:
Run to see the data returned by the interface at this time:
https://localhost:44378/api/User/
As you can see, what is returned is already a standard JSON serialized data. If you are careful enough, you should see some extra spaces in the data! We will explain the reason behind this. You can focus on the format first.
Now let's modify the interface to return the data in the format we specified. Refer to the following figure, set the return format globally, we only need to clear the default XML format.
GlobalConfiguration.Configuration.Formatters.XmlFormatter.SupportedMediaTypes.Clear();
Save and run, let's take a look at the return of the interface: you can see that the format has been changed.
Let's take a look at the data problem now. The data we expect from the interface should be in the following format:
{"status":1,"data":[{"id":"1265984563","name":"Bill","sex":"f ","mobile":null,"nickName":null,"address":null,"headerIcon":null,"birthDay":null,"password":null}],"msg":"查询成功"}
Features: "data": [] instead of "data": "[]", if you put double quotes, there is no problem, but this leads to the parsing in the front-end parsing, especially when the APP parsing The device has to work twice, take out the data string and parse it again to get the data that the front end expects! This is certainly not possible, and it is not allowed! Today, performance is king, how can we do the same thing repeatedly? However, our interface returns. . .
First, the data node of the above data should be an object, but it is a string?
Second, there are extra spaces in some fields. What is the situation?
Ok, let's deal with them one by one.
Why is it a string? This is because we are redundantly serializing objects! We only need to modify the following points slightly:
Let's run it again, let's see the effect. Is it normal for "data": [] ? ! ! ! !
The second problem, there are extra spaces, don't want this simple gangster! The reason is that when the design of our database table, the column attribute is nchar type, the characteristics of this type are compared with varchar, etc. The students will search and study on their own, and I wo n’t discuss it in depth here. Since it is a question of the table, we can change it. Open the database SSMS client: redesign the following table, modify the column attributes to: varchar, save the file.
When saving, it will remind you:
Click Yes. When to use nchar and when to use varchar, we will study and discuss in depth later. I will ignore it for now, if you are interested, you can search and learn by yourself.
After the modification is complete, don't rush to run the project, the database has been modified, and our EF data model has not been updated! You now have the same result, or a bunch of blanks! ! !
Select the DataProvider project and double-click the Model.edmx file:
Right-click in the blank space and select "Update Model from Database" to update the data model again.
Because we have not added any new tables, there is no new table in the table area, just click Finish.
The data problem is because when it was inserted in the second lecture, there was already a problem with the type, so we update the data in the table.
Let's run the project again, let's look at the return of the interface! As you can see, all the problems we face have been solved!
{"status":1,"data":[{"id":"1265984563","name":"bills","sex":"f","mobile":null,"nickName":null,"address":null,"headerIcon":null,"birthDay":null,"password":null}],"msg":"查询成功"}
That's all for this tutorial. In the next section, let's continue to expand our table to realize more business and logic.
