I've never seen an update coded this way. You do check in the id passed in the Url is the same as that passed in the payload, which is good. You don't do any null checking after line 80, so if that id isn't in the db, you will get a null reference error. The common way I see this done it more along the lines of: Check IsValid and return View() if it's not. Do the db query. Check if the result is null, if so, return a notfound or redirect to a not found page. Update the object retrieved from the db and save changes. But, these days, I also prefer task based UI. Rather than sending the full entity from the client, send an UpdateDescription command so it's clear the users intent.
@rahulawasthi886 Жыл бұрын
3 weeks gone. No new video. We are waiting.....
@komando005 Жыл бұрын
Thanks for your effort your videos are really good keep going brother 💪
@DotNetMastery Жыл бұрын
thank you so much!
@ranaabushammalh2152 Жыл бұрын
Can you extend the special offer on this course RESTful Web API - The Complete Guide (.NET7 API) Part 1 in Udemy ...for two days because I wanted to buy it but was not able to buy it in the previous days. Please, I have bought .NET Core MVC - The Complete Guide 2023 course:(((
@vikasrajput6135 Жыл бұрын
Thanks much
@JamesYGGoY Жыл бұрын
Can you give a little more detail into why you would want your entity not tracked by your context?
@DotNetMastery Жыл бұрын
Because in the Update we are passing an entity. at that time EF will add a tracker on that entity based on the primary key buy if you are already tracking because of first or default, EF cannot track same entity again.
@JamesYGGoY Жыл бұрын
@@DotNetMastery so, it's because of the Edit it seems. I was thinking of a scenario where the record we have in the database is legitimately different, but by random chance, the Id's matched, in which case, we wouldn't want to overwrite - but my scenario is a create scenario now that I think more on it. Thanks! I'm enjoying this series, keep it up!