Join Alexander Zanfir for an in-depth discussion in this video Edit question route in ASP.NET, part of Building Applications with Angular, ASP.NET Core, and Entity Framework Core.
- [Instructor] In this video, we'll create an end point on our back end, which will allow us to edit the question. Let's begin by opening up our sample values controller. Then let's scroll down to the put function on line 34, and we'll copy that. Then let's paste it below our post function in our questions controller. Then let's modify the parameter we take in so that we get a question instead of a string. So I'll copy what we have as our parameter from our post function, and paste it as a second parameter in our put function.
Next let's try this out with Postman. So I'll set a break point on line 36, and let's get the server started. Then inside our Postman, let's change the action from post to put. And before we try it, since our put takes an ID in the first parameter, so if we take a look at our function, we can see we need to get the ID of whatever question we'd like to edit or put the changes into, we need to add that with a slash and then the ID to the URL.
Now let's try to hit send. We can see the break point has triggered, and if we hover over question, we can see we're getting our text. Let's stop our server and then modify our function so that we get reference to the question of the ID that we're passing in. So we'll create a variable called question, and then I'll change the second parameter from question to question data, so that we don't get a conflict.
And then we'll search through our questions collection using single or default. And I could use the default synchronous call, but I'd like to demonstrate the asynchronous call at this point, so I'll use the keyword await, and then we'll access our questions through context. And we'll return a single or default with the async call. And in order to use await, we'll need to designate this function as async.
So I'll add that in front of the return type. And to use single or default async versus the synchronous traditional method, we'll need to add, at the top of our controller, using Microsoft dot entity framer core. And so I'm not scrolling as much horizontally, I'm going to pin down our solution explorer.
And then we'll select the question by ID. So we'll pass in a question, and we'll check that the question dot ID matches the ID we passed into our put function. And then let's simply return the question, with okay, and pass question as a parameter. And to do that, instead of using void as the return type on line 36, we'll change that to task, of type I, action result.
And I'll take off the break point. But before we give that a try, we need to know the ID of a question currently inside a database. And since we're not seeding the database yet, we're going to have to add a question, and then figure out its ID. And typically when an HTTP post is successfully made, it returns the object with its ID that was just added. So let's go up to our post function on line 29 and make those changes. And again, instead of void, we'll change that to a task, with type I action result.
And I'll convert this to an async function as well, so I'll add async in front of the return type. And then instead of calling context dot save changes, on line 32, I'll call context dot save changes async. And then add await in front. Once the save changes are complete, and then we can return an okay with the question. So let's give that a try.
So back inside Postman, let's go to our original post command. Check the body, and then hit send. And now if we scroll down, we can see we were returned a question with the ID one. So now we can go back to our original request of put, and then specify ID one. Let's give that a try. And we're getting back the question, so we know it was able to find it and return it to us. Now we just need to actually modify its values.
So let's stop the server and then go back to our put function. And then what we'll do is simply tell context that a question has been modified, so we'll use context dot entry, and we'll pass in question, data, dot state, and we'll set it to entity state dot modified. So we're telling our context that the question we get inside our question data parameter, that once it finds it, set its state to modified, and then all we need to do is save changes.
But the nice thing about using context dot entry is that we no longer have to find it ourselves, so we can get rid of our questions dot single or default on line 39. Now all we need to do is call await, context, dot save changes async. And then we can return questions data. And since we no longer have a variable called question from our single or default search, I can rename this back to question.
Let's save that and give it a try. So we'll begin by posting a new question, and we received our question back with an ID, so we know it was saved. Then let's go to our put, and I've changed the value from test to test two. And let's send that. And notice that we're getting an error. Let's go to preview so we can see it formatted better. We can see that an attempt to update or delete an entity that does not exist in the store.
So let's go back to Visual Studio to see what's happening. Previously we were searching for the question ourselves manually using single or default, and we searched by ID. Context dot entry, on the other hand, uses the ID from the model itself, not the ID parameter we pass in. And so, we have to pretend that we have the ID when we're sending it with our put data. So in that case, I'll add ID as a second property.
So let's give that a try. And there we go, now we're able to get our question back with the updated value. There's a couple things you might be wondering at this point. Why is there an ID passed into put, when there's an ID inside the question model itself? The reason is, it lets us explicitly specify in the URL what question we'd like to update. So if we thought we were trying to modify question two, but instead we actually had the data for question one, we would get back some error.
And so to handle that, we'll add a check at the top of our put function. So if ID does not match question dot ID, we'll return a bad request. Let's give that a try. So I'll post a question. We have ID one. And then, I'll leave it as ID two in the URL, but there will be ID one specified in the object.
If we try to send that, we'll get back a 400 bad request. And if we specify the correct ID, we'll be able to change it. The next thing you might be wondering is why I changed these functions from asynchronous to synchronous, and is one better than the other. There's usually not a general answer for that, it depends on the situation. So depending on the web server you're using, such as IIS, it might be able to handle a lot more threads or requests than the database we're trying to access.
In that case the bottleneck won't be in the web server itself, but possibly in the database, and so async won't be that valuable in that case. But with the modern database server, it might make sense to use async inside our controllers so that we can handle more simultaneous requests. And that needs to be assessed based on your project or on a per-controller or per-call basis. With this, I just wanted to show you that there are two possible options you can use whether it's synchronous or asynchronous.
So now that we're able to edit from Postman, let's move on to making our edits from our Angular web app.
- Creating and configuring the Angular project
- Creating forms with Angular
- Creating get and post routes in an ASP.NET Core controller
- Updating Angular service to post to API
- Persistence with Entity Framework
- Displaying and editing data in Angular with ASP.NET Core
- Navigating to different views in Angular
- Associations between entities with Angular and Entity Framework
- Setting up Identity Framework