Editing entities without breaking the network tab (part 1/5)

Photo by Patrick Brinksma on Unsplash

This is the first step of our example for implementing batch editing with the Ignite UI for Angular Grid control and Web API. We will use the Transaction service that we at Infragistics have developed to allow accumulation of changes without immediately affecting the underlying data.

In the following blog series, we are going to provide detailed guidance on how to implement batch updating in an Angular application with an Ignite UI for Angular Grid component, using Web API with Entity Framework as our back end. This article not only walks through the steps required but also provides information on the possible trouble points you may face while integrating the different parts of the solution to work with each other.

The application I am building is intended to provide users with UI to perform a number of CRUD operations on the data. The front end is an Angular application, with an IgxGrid component displaying the data and providing the editing interface for the end-users. The updates are then sent to the server for each change, in order to update the server state of the entities. However, this creates a large number of requests to the server, and I am going to show how this can be optimized by sending a batch of updates all at once, instead of processing each individual update separately.

We will execute those steps in our scenario:

1. Create a Web API with Entity Framework
2. Update the controller that would get the transactions from the client-side and would update the database
3. Create an Angular application with IgxGrid using the Ignite UI CLI
4. Update the Ignite UI CLI project in order to work with the Web API
5. Send the request to the server and update the database

We will note the prerequisites at the beginning of every step. So, let us get excited and jump into creating our first Angular application with IgxGrid and batch updating!

Step 1: Create a Web API with Entity Framework

In this section, we use:

• Visual Studio 2017
• Web API 2.1
• Entity Framework 6
• .NET 4.6.1

Open Visual Studio and create a new project. Select File > New > Project.

When in the “New project” view, select “Web” from the “Visual C#” templates and choose “ASP.NET Web Application (.NET Framework)” project. Name your new project CityService and click OK.

In the following view, choose “Web API”. Leave all the checkboxes as they are and click OK.

At this point, we have our new project created. You may look at the project structure in the Solution Explorer and investigate how the skeleton of our Web API looks like.

The first thing we should add to the solution is our model class. In this project, we will create our database using the “Code First” approach to Entity Framework. We will code our class and the properties that correspond to tables and columns in the database. The mapping between the store schema and the conceptual model represented by our code is handled by convention and by a special mapping API.

You may find more information on the different EF Development approaches in this section of the Microsoft documentation. We will not spend time here to explain the specifics of the other two approaches. We should only note that they are called “Database First” and “Model First” and that it is strongly recommended to go with the “Code First” approach if you are a newcomer to Entity Framework. Good thing that we are demonstrating this approach in our post!

Now let us get to creating the City class. Right-click the Models folder and select Add > Class.

Name the created class City.

Delete the content of the newly created file and replace it with the following code:

If we look into our model, we would see that we would show the end users the name of the city, its population, if there is a train station in the city when is the city holiday and we would provide a brief description — may be interesting tourist attractions, restaurants, etc.

Now when we have our model, let us create the Web API controller that would receive the updates coming from the client-side and would communicate with the database layer using Entity Framework.

Expand the Controllers folder and you would see there are already two controllers created. HomeController.cs and ValuesController.cs. The ValuesController is just an example Web API controller and you may delete it to make our project easier to navigate.

After the example controller is deleted, build your project as the Web API scaffolding uses reflection to find the model classes, so it needs the compiled assembly. Next, right-click the Controllers folder and choose Add > Controller.

When in the “Add Scaffold” view, select “Web API 2 Controller with actions, using Entity Framework”. Click Add.

An “Add Controller” view is opened. Open the “Model Class” dropdown list and select the City class. If the City class is missing from the list, make sure that you have built the project prior to creating the controller.

Check the “Use async controller actions” checkbox below and leave the controller name as CitiesController.

Next click the plus (+) button next to “Data Context Class”.

Inside the “New Data Context” view leave the value as it is: CityService.Models.CityServiceContext. At this point, the “Add Controller” dialog looks like this:

Now click “Add”.

Visual Studio needs a bit of time to install some required NuGet packages and to scaffold the structure that we have setup. Once the build succeeds, you would see that two classes were added to your project.

Now, let us see what those files stand for.

The CitiesController, of course, defines a Web API controller. Currently, the controller implements the REST API that clients use to perform CRUD operations on a list of authors. And here is a tricky note! We do not actually need the controller in its current state as we want to execute batch updating and not to perform operation by operation. For the moment, we may leave it like this. We will get back to it in a minute. Let us first see what is the second class that was added to our project.

The CityServiceContext.cs was added under the Models folder. It manages entity objects during run time, which includes populating objects with data from a database, changes tracking, and persisting data to the database. It inherits from DbContext. If you want to understand more about the DbContext class, its properties and methods (some of them we will use in the following sections), you may read this topic.

Now build your project again as we are going to use Code First Migrations to seed our database!

What exactly is Code First Migrations? Migrations allow us to create an initial database that works with our Entity Framework model, to generate migrations to keep track of changes that we make to the model and to keep our database up to date with those changes. In case you are interested in learning more about Migrations, you may read the following article.

Let us continue by navigating to the “Tools” menu and select NuGet Package Manager > Package Manager Console. Inside the console that is opened, provide the following command:

Enable-Migrations

The first thing this command would do is to check if the context targets an existing database, which is not the case in our project. Then the Code First Migration would be enabled for the project. After you see that the command is executed as expected, you would also notice that it has added a new folder named “Migrations” to our project. Inside this new folder is created a code file named Configuration.cs.

Open the Configuration.cs file and add this using statement:

Then you would delete the commented block of code and would provide the initial data for our application to the Seed method. Paste the following code inside the Seed method:

Now, after we have provided the data we want to show in our IgxGrid, let us go back to the Package Manager Console and execute the following command:

Add-Migration Initial

After this is executed, run this command:

Update-Database

After executing both commands, your console would look like this:

Well done! At this point, we do have a working Web API! Let us see what it looks like. Build the project and run it using Ctrl+F5.

Our project opens in our default browser and you may navigate to the API tab in the navigation menu where you would find the available API methods! Exciting, isn’t it?

Wait a minute! Our Web API is up and running but in its current state, it is only able to process separate requests for each update made on the client-side. In the following step, we will update the controller to achieve batch updating functionality.

Thank you for following up with me through this exciting example.
You may continue our journey in the second part of this series on implementing the batch editing feature of the Ignite UI for Angular Grid.