Editing entities without breaking the network tab (part 2/5)
This is the second step of our example for implementing batch editing with the Ignite UI for Angular Grid control and Web API. You may find the previous step, in which we have created the Web API, here.
Step 2: Update the controller that would get the transactions from the client-side and would update the database
In this section, we will update our controller in order to process the transactions coming from our client-side application and to update the database with the changes.
Before beginning with the implementation, we should step back to analyze the different approaches we may use to communicate between the client-side and the Web API in the context of batch editing.
The first approach, that we would follow in our example, is to send all the transactions to the server in a single request and then iterate over each transaction on the server, saving the changes to the database.
The second option is to group all the transactions by type and send an individual request to the backend for each type of grouped transactions, for a maximum of three requests.
The third choice we have for implementing batch updating is based on the mime/multipart content type. It accepts mime/multipart requests containing multiple HTTP requests and processes all the requests sending a mime/multipart response containing the individual responses. This approach requires additional changes on the client-side as well as in the Web API and we will not implement it in our example. However, if you want to use this approach — you may follow the guidance that Microsoft provides in this document.
Now, let us continue with implementing the first approach we mentioned above — sending all the transactions in a single request and processing it on the server.
Open the CitiesController.cs file and navigate to the bottom of the code. Before the closing curly bracket of the CitiesController public class, we will create an Interface for the transaction we would get from the client-side. Paste the following code there:
Now, delete the whole content of the CitiesController class up to the ITransaction interface that we have created and replace it with the following code:
Now let us go through the updates we made and see what our controller is capable of.
The first thing we see is that it has a GET method GetCities() that returns all the records that are in our database. We will use this method to access the data and to load it in the IgxGrid component that we will create in the next step.
Below, we have an PostCity() method that accepts the transaction that would come from the client-side. From our client-side, we will make a POST request that contains all the changes that we have made to this IHttpActionResult.
What will happen when we send the transactions to this IHttpActionResult is that it will iterate through all the transactions included in the request and will check what type of operation every transaction is — update (if we are updating an existing record), add (if we have added a new city) or delete (if we are deleting a record that existed in the database).
To update a record we are using the SetValues() method of the DbPropertyValues class. What it does is to read the values out of the given object and set the values of the dictionary. When you take a look at the example for this section that is available on Github, you would notice that a block of code that is commented out demonstrates another way of handling the update — you may assign the properties one by one. Our suggestion is to go for the first option as it makes the code easier to read. However, if, for a reason, you want to use the second approach just comment out this line:
And then uncomment this block:
A publication that provides more information on this topic could be found here.
Adding a new record to the database or deleting one is self-explanatory as those are done using those lines of code:
for adding a record and
for deleting a record.
After all the transactions that were sent to the back end are processed, we call the SaveChanges() method that saves all changes made in this context to the underlying database. We should always place the SaveChanges() method inside a try-catch block. In our case, if an error is thrown, we would return its message.
If no exception is thrown, we return an “OK Result” (200 OK).
This is the Web API implementation if we want to send a single request, containing all our updates to the server and to process it there. Now let us quickly look at how our Web API would look like if we want to use the second approach that we have described — sending all the transactions in different requests to different endpoints on the server.
First, we need to comment out the PostCity() method. Then we should add the following methods above it. They are serving as endpoints for the delete, add and update requests respectively:
And that is it! Now we have a Web API that may process batch updates coming from the IgxGrid. This means it is time to look at our client-side and to set up the IgxGrid that will consume our data and will allow us to update it using smooth and elegant UI.
Thank you for following up with me through the second part of this example.
You will see how the controller looks after our updates here. We will continue our journey in the third part of this series on implementing the batch editing feature of the Ignite UI for Angular Grid.
