Deel 10, bekijk de details en verwijdermethoden van een ASP.NET Core-app
Notitie
Dit is niet de nieuwste versie van dit artikel. Zie de .NET 9-versie van dit artikelvoor de huidige release.
Waarschuwing
Deze versie van ASP.NET Core wordt niet meer ondersteund. Zie de .NET- en .NET Core-ondersteuningsbeleidvoor meer informatie. Zie de .NET 9-versie van dit artikelvoor de huidige release.
Belangrijk
Deze informatie heeft betrekking op een pre-releaseproduct dat aanzienlijk kan worden gewijzigd voordat het commercieel wordt uitgebracht. Microsoft geeft geen garanties, uitdrukkelijk of impliciet, met betrekking tot de informatie die hier wordt verstrekt.
Zie de .NET 9-versie van dit artikelvoor de huidige release.
Door Rick Anderson
Open de filmcontroller en bekijk de methode Details
:
// GET: Movies/Details/5
public async Task<IActionResult> Details(int? id)
{
if (id == null)
{
return NotFound();
}
var movie = await _context.Movie
.FirstOrDefaultAsync(m => m.Id == id);
if (movie == null)
{
return NotFound();
}
return View(movie);
}
De MVC-scaffolding-engine die deze actiemethode heeft gemaakt, voegt een opmerking toe met een HTTP-aanvraag die de methode aanroept. In dit geval is het een GET-aanvraag met drie URL-segmenten, de Movies
controller, de Details
methode en een id
waarde. Zoals u weet, worden deze segmenten gedefinieerd in Program.cs
.
app.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
MET EF kunt u eenvoudig zoeken naar gegevens met behulp van de methode FirstOrDefaultAsync
. Een belangrijke beveiligingsfunctie die is ingebouwd in de methode, is dat de code controleert of de zoekmethode een film heeft gevonden voordat er iets mee wordt geprobeerd te doen. Een hacker kan bijvoorbeeld fouten in de site veroorzaken door de URL te wijzigen die is gemaakt door de koppelingen van http://localhost:{PORT}/Movies/Details/1
naar iets zoals http://localhost:{PORT}/Movies/Details/12345
(of een andere waarde die geen echte film vertegenwoordigt). Als u niet hebt gecontroleerd op een null-film, genereert de app een uitzondering.
Bekijk de methoden Delete
en DeleteConfirmed
.
// GET: Movies/Delete/5
public async Task<IActionResult> Delete(int? id)
{
if (id == null)
{
return NotFound();
}
var movie = await _context.Movie
.FirstOrDefaultAsync(m => m.Id == id);
if (movie == null)
{
return NotFound();
}
return View(movie);
}
// POST: Movies/Delete/5
[HttpPost, ActionName("Delete")]
[ValidateAntiForgeryToken]
public async Task<IActionResult> DeleteConfirmed(int id)
{
var movie = await _context.Movie.FindAsync(id);
if (movie != null)
{
_context.Movie.Remove(movie);
}
await _context.SaveChangesAsync();
return RedirectToAction(nameof(Index));
}
Houd er rekening mee dat de HTTP GET Delete
-methode de opgegeven film niet verwijdert. Het retourneert een weergave van de film waarin u de verwijdering kunt verzenden (HttpPost). Als u een verwijderingsbewerking uitvoert als reactie op een GET-aanvraag (of als u een bewerking uitvoert, een bewerking maakt of een andere bewerking waarmee gegevens worden gewijzigd), wordt er een beveiligingsgat geopend.
De [HttpPost]
methode waarmee de gegevens worden verwijderd, heet DeleteConfirmed
om de HTTP POST-methode een unieke handtekening of naam te geven. De twee methodesignaturen worden hieronder weergegeven.
// GET: Movies/Delete/5
public async Task<IActionResult> Delete(int? id)
{
// POST: Movies/Delete/5
[HttpPost, ActionName("Delete")]
[ValidateAntiForgeryToken]
public async Task<IActionResult> DeleteConfirmed(int id)
{
Voor de Common Language Runtime (CLR) moeten overbelaste methoden een unieke parameterhandtekening hebben (dezelfde methodenaam maar een andere lijst met parameters). Hier hebt u echter twee Delete
methoden nodig, één voor GET en één voor POST, die beide dezelfde parameterhandtekening hebben. (Beide moeten één geheel getal als parameter accepteren.)
Er zijn twee benaderingen voor dit probleem: u kunt de methoden verschillende namen geven. Dat is wat het steigeringsmechanisme in het voorgaande voorbeeld heeft gedaan. Dit introduceert echter een klein probleem: ASP.NET segmenten van een URL toewijzen aan actiemethoden op naam en als u de naam van een methode wijzigt, kan routering die methode normaal gesproken niet vinden. De oplossing is wat u in het voorbeeld ziet. Dit is het toevoegen van het kenmerk ActionName("Delete")
aan de methode DeleteConfirmed
. Dit kenmerk voert toewijzingen uit voor het routeringssysteem, zodat een URL die /Delete/ voor een POST-aanvraag bevat, de DeleteConfirmed
methode vindt.
Een andere veelgebruikte oplossing voor methoden met identieke namen en handtekeningen is het kunstmatig wijzigen van de handtekening van de POST-methode om een extra (ongebruikte) parameter op te nemen. Dat is wat we in een vorige post hebben gedaan toen we de parameter notUsed
toevoegden. U kunt hier hetzelfde doen voor de [HttpPost] Delete
methode:
// POST: Movies/Delete/6
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Delete(int id, bool notUsed)
Publiceren naar Azure
Zie Zelfstudie: Een ASP.NET Core- en SQL Database-app bouwen in Azure App Servicevoor meer informatie over het implementeren in Azure.
Patronen voor bedrijfsweb-apps
Zie Enterprise-web-app-patronenvoor hulp bij het maken van een betrouwbare, veilige, uitvoerbare, testbare en schaalbare ASP.NET Core-app. Er is een volledige voorbeeldweb-app van productiekwaliteit beschikbaar waarmee de patronen worden geïmplementeerd.
Open de filmcontroller en bekijk de methode Details
:
// GET: Movies/Details/5
public async Task<IActionResult> Details(int? id)
{
if (id == null)
{
return NotFound();
}
var movie = await _context.Movie
.FirstOrDefaultAsync(m => m.Id == id);
if (movie == null)
{
return NotFound();
}
return View(movie);
}
De MVC-scaffolding-engine die deze actiemethode heeft gemaakt, voegt een opmerking toe met een HTTP-aanvraag die de methode aanroept. In dit geval is het een GET-aanvraag met drie URL-segmenten, de Movies
controller, de Details
methode en een id
waarde. Zoals u weet, worden deze segmenten gedefinieerd in Program.cs
.
app.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
MET EF kunt u eenvoudig zoeken naar gegevens met behulp van de methode FirstOrDefaultAsync
. Een belangrijke beveiligingsfunctie die is ingebouwd in de methode, is dat de code controleert of de zoekmethode een film heeft gevonden voordat er iets mee wordt geprobeerd te doen. Een hacker kan bijvoorbeeld fouten in de site veroorzaken door de URL te wijzigen die is gemaakt door de koppelingen van http://localhost:{PORT}/Movies/Details/1
naar iets zoals http://localhost:{PORT}/Movies/Details/12345
(of een andere waarde die geen echte film vertegenwoordigt). Als u niet hebt gecontroleerd op een null-film, genereert de app een uitzondering.
Bekijk de methoden Delete
en DeleteConfirmed
.
// GET: Movies/Delete/5
public async Task<IActionResult> Delete(int? id)
{
if (id == null)
{
return NotFound();
}
var movie = await _context.Movie
.FirstOrDefaultAsync(m => m.Id == id);
if (movie == null)
{
return NotFound();
}
return View(movie);
}
// POST: Movies/Delete/5
[HttpPost, ActionName("Delete")]
[ValidateAntiForgeryToken]
public async Task<IActionResult> DeleteConfirmed(int id)
{
var movie = await _context.Movie.FindAsync(id);
if (movie != null)
{
_context.Movie.Remove(movie);
}
await _context.SaveChangesAsync();
return RedirectToAction(nameof(Index));
}
Houd er rekening mee dat de HTTP GET Delete
-methode de opgegeven film niet verwijdert. Het retourneert een weergave van de film waarin u de verwijdering kunt verzenden (HttpPost). Als u een verwijderingsbewerking uitvoert als reactie op een GET-aanvraag (of als u een bewerking uitvoert, een bewerking maakt of een andere bewerking waarmee gegevens worden gewijzigd), wordt er een beveiligingsgat geopend.
De [HttpPost]
methode waarmee de gegevens worden verwijderd, heet DeleteConfirmed
om de HTTP POST-methode een unieke handtekening of naam te geven. De twee methodesignaturen worden hieronder weergegeven.
// GET: Movies/Delete/5
public async Task<IActionResult> Delete(int? id)
{
// POST: Movies/Delete/5
[HttpPost, ActionName("Delete")]
[ValidateAntiForgeryToken]
public async Task<IActionResult> DeleteConfirmed(int id)
{
Voor de Common Language Runtime (CLR) moeten overbelaste methoden een unieke parameterhandtekening hebben (dezelfde methodenaam maar een andere lijst met parameters). Hier hebt u echter twee Delete
methoden nodig, één voor GET en één voor POST, die beide dezelfde parameterhandtekening hebben. (Beide moeten één geheel getal als parameter accepteren.)
Er zijn twee benaderingen voor dit probleem: u kunt de methoden verschillende namen geven. Dat is wat het steigeringsmechanisme in het voorgaande voorbeeld heeft gedaan. Dit introduceert echter een klein probleem: ASP.NET segmenten van een URL toewijzen aan actiemethoden op naam en als u de naam van een methode wijzigt, kan routering die methode normaal gesproken niet vinden. De oplossing is wat u in het voorbeeld ziet. Dit is het toevoegen van het kenmerk ActionName("Delete")
aan de methode DeleteConfirmed
. Dit kenmerk voert toewijzingen uit voor het routeringssysteem, zodat een URL die /Delete/ voor een POST-aanvraag bevat, de DeleteConfirmed
methode vindt.
Een andere veelgebruikte oplossing voor methoden met identieke namen en handtekeningen is het kunstmatig wijzigen van de handtekening van de POST-methode om een extra (ongebruikte) parameter op te nemen. Dat is wat we in een vorige post hebben gedaan toen we de parameter notUsed
toevoegden. U kunt hier hetzelfde doen voor de [HttpPost] Delete
methode:
// POST: Movies/Delete/6
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Delete(int id, bool notUsed)
Publiceren naar Azure
Zie Zelfstudie: Een ASP.NET Core- en SQL Database-app bouwen in Azure App Servicevoor meer informatie over het implementeren in Azure.
Patronen voor bedrijfsweb-apps
Zie Enterprise-web-app-patronenvoor hulp bij het maken van een betrouwbare, veilige, uitvoerbare, testbare en schaalbare ASP.NET Core-app. Er is een volledige voorbeeldweb-app van productiekwaliteit beschikbaar waarmee de patronen worden geïmplementeerd.
Open de filmcontroller en bekijk de methode Details
:
// GET: Movies/Details/5
public async Task<IActionResult> Details(int? id)
{
if (id == null)
{
return NotFound();
}
var movie = await _context.Movie
.FirstOrDefaultAsync(m => m.Id == id);
if (movie == null)
{
return NotFound();
}
return View(movie);
}
De MVC-scaffolding-engine die deze actiemethode heeft gemaakt, voegt een opmerking toe met een HTTP-aanvraag die de methode aanroept. In dit geval is het een GET-aanvraag met drie URL-segmenten, de Movies
controller, de Details
methode en een id
waarde. Zoals u weet, worden deze segmenten gedefinieerd in Program.cs
.
app.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
MET EF kunt u eenvoudig zoeken naar gegevens met behulp van de methode FirstOrDefaultAsync
. Een belangrijke beveiligingsfunctie die is ingebouwd in de methode, is dat de code controleert of de zoekmethode een film heeft gevonden voordat er iets mee wordt geprobeerd te doen. Een hacker kan bijvoorbeeld fouten in de site veroorzaken door de URL te wijzigen die is gemaakt door de koppelingen van http://localhost:{PORT}/Movies/Details/1
naar iets zoals http://localhost:{PORT}/Movies/Details/12345
(of een andere waarde die geen echte film vertegenwoordigt). Als u niet hebt gecontroleerd op een null-film, genereert de app een uitzondering.
Bekijk de methoden Delete
en DeleteConfirmed
.
// GET: Movies/Delete/5
public async Task<IActionResult> Delete(int? id)
{
if (id == null)
{
return NotFound();
}
var movie = await _context.Movie
.FirstOrDefaultAsync(m => m.Id == id);
if (movie == null)
{
return NotFound();
}
return View(movie);
}
// POST: Movies/Delete/5
[HttpPost, ActionName("Delete")]
[ValidateAntiForgeryToken]
public async Task<IActionResult> DeleteConfirmed(int id)
{
var movie = await _context.Movie.FindAsync(id);
if (movie != null)
{
_context.Movie.Remove(movie);
}
await _context.SaveChangesAsync();
return RedirectToAction(nameof(Index));
}
Houd er rekening mee dat de HTTP GET Delete
-methode de opgegeven film niet verwijdert. Het retourneert een weergave van de film waarin u de verwijdering kunt verzenden (HttpPost). Als u een verwijderingsbewerking uitvoert als reactie op een GET-aanvraag (of als u een bewerking uitvoert, een bewerking maakt of een andere bewerking waarmee gegevens worden gewijzigd), wordt er een beveiligingsgat geopend.
De [HttpPost]
methode waarmee de gegevens worden verwijderd, heet DeleteConfirmed
om de HTTP POST-methode een unieke handtekening of naam te geven. De twee methodesignaturen worden hieronder weergegeven.
// GET: Movies/Delete/5
public async Task<IActionResult> Delete(int? id)
{
// POST: Movies/Delete/5
[HttpPost, ActionName("Delete")]
[ValidateAntiForgeryToken]
public async Task<IActionResult> DeleteConfirmed(int id)
{
Voor de Common Language Runtime (CLR) moeten overbelaste methoden een unieke parameterhandtekening hebben (dezelfde methodenaam maar een andere lijst met parameters). Hier hebt u echter twee Delete
methoden nodig, één voor GET en één voor POST, die beide dezelfde parameterhandtekening hebben. (Beide moeten één geheel getal als parameter accepteren.)
Er zijn twee benaderingen voor dit probleem: u kunt de methoden verschillende namen geven. Dat is wat het steigeringsmechanisme in het voorgaande voorbeeld heeft gedaan. Dit introduceert echter een klein probleem: ASP.NET segmenten van een URL toewijzen aan actiemethoden op naam en als u de naam van een methode wijzigt, kan routering die methode normaal gesproken niet vinden. De oplossing is wat u in het voorbeeld ziet. Dit is het toevoegen van het kenmerk ActionName("Delete")
aan de methode DeleteConfirmed
. Dit kenmerk voert toewijzingen uit voor het routeringssysteem, zodat een URL die /Delete/ voor een POST-aanvraag bevat, de DeleteConfirmed
methode vindt.
Een andere veelgebruikte oplossing voor methoden met identieke namen en handtekeningen is het kunstmatig wijzigen van de handtekening van de POST-methode om een extra (ongebruikte) parameter op te nemen. Dat is wat we in een vorige post hebben gedaan toen we de parameter notUsed
toevoegden. U kunt hier hetzelfde doen voor de [HttpPost] Delete
methode:
// POST: Movies/Delete/6
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Delete(int id, bool notUsed)
Publiceren naar Azure
Zie Zelfstudie: Een ASP.NET Core- en SQL Database-app bouwen in Azure App Servicevoor meer informatie over het implementeren in Azure.
Open de filmcontroller en bekijk de methode Details
:
// GET: Movies/Details/5
public async Task<IActionResult> Details(int? id)
{
if (id == null)
{
return NotFound();
}
var movie = await _context.Movie
.FirstOrDefaultAsync(m => m.Id == id);
if (movie == null)
{
return NotFound();
}
return View(movie);
}
De MVC-scaffolding-engine die deze actiemethode heeft gemaakt, voegt een opmerking toe met een HTTP-aanvraag die de methode aanroept. In dit geval is het een GET-aanvraag met drie URL-segmenten, de Movies
controller, de Details
methode en een id
waarde. Zoals u weet, worden deze segmenten gedefinieerd in Program.cs
.
app.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
MET EF kunt u eenvoudig zoeken naar gegevens met behulp van de methode FirstOrDefaultAsync
. Een belangrijke beveiligingsfunctie die is ingebouwd in de methode, is dat de code controleert of de zoekmethode een film heeft gevonden voordat er iets mee wordt geprobeerd te doen. Een hacker kan bijvoorbeeld fouten in de site veroorzaken door de URL te wijzigen die is gemaakt door de koppelingen van http://localhost:{PORT}/Movies/Details/1
naar iets zoals http://localhost:{PORT}/Movies/Details/12345
(of een andere waarde die geen echte film vertegenwoordigt). Als u niet hebt gecontroleerd op een null-film, genereert de app een uitzondering.
Bekijk de methoden Delete
en DeleteConfirmed
.
// GET: Movies/Delete/5
public async Task<IActionResult> Delete(int? id)
{
if (id == null)
{
return NotFound();
}
var movie = await _context.Movie
.FirstOrDefaultAsync(m => m.Id == id);
if (movie == null)
{
return NotFound();
}
return View(movie);
}
// POST: Movies/Delete/5
[HttpPost, ActionName("Delete")]
[ValidateAntiForgeryToken]
public async Task<IActionResult> DeleteConfirmed(int id)
{
var movie = await _context.Movie.FindAsync(id);
_context.Movie.Remove(movie);
await _context.SaveChangesAsync();
return RedirectToAction(nameof(Index));
}
Houd er rekening mee dat de HTTP GET Delete
-methode de opgegeven film niet verwijdert. Het retourneert een weergave van de film waarin u de verwijdering kunt verzenden (HttpPost). Als u een verwijderingsbewerking uitvoert als reactie op een GET-aanvraag (of als u een bewerking uitvoert, een bewerking maakt of een andere bewerking waarmee gegevens worden gewijzigd), wordt er een beveiligingsgat geopend.
De [HttpPost]
methode waarmee de gegevens worden verwijderd, heet DeleteConfirmed
om de HTTP POST-methode een unieke handtekening of naam te geven. De twee methodesignaturen worden hieronder weergegeven.
// GET: Movies/Delete/5
public async Task<IActionResult> Delete(int? id)
{
// POST: Movies/Delete/5
[HttpPost, ActionName("Delete")]
[ValidateAntiForgeryToken]
public async Task<IActionResult> DeleteConfirmed(int id)
{
Voor de Common Language Runtime (CLR) moeten overbelaste methoden een unieke parameterhandtekening hebben (dezelfde methodenaam maar een andere lijst met parameters). Hier hebt u echter twee Delete
methoden nodig, één voor GET en één voor POST, die beide dezelfde parameterhandtekening hebben. (Beide moeten één geheel getal als parameter accepteren.)
Er zijn twee benaderingen voor dit probleem: u kunt de methoden verschillende namen geven. Dat is wat het steigeringsmechanisme in het voorgaande voorbeeld heeft gedaan. Dit introduceert echter een klein probleem: ASP.NET segmenten van een URL toewijzen aan actiemethoden op naam en als u de naam van een methode wijzigt, kan routering die methode normaal gesproken niet vinden. De oplossing is wat u in het voorbeeld ziet. Dit is het toevoegen van het kenmerk ActionName("Delete")
aan de methode DeleteConfirmed
. Dit kenmerk voert toewijzingen uit voor het routeringssysteem, zodat een URL die /Delete/ voor een POST-aanvraag bevat, de DeleteConfirmed
methode vindt.
Een andere veelgebruikte oplossing voor methoden met identieke namen en handtekeningen is het kunstmatig wijzigen van de handtekening van de POST-methode om een extra (ongebruikte) parameter op te nemen. Dat is wat we in een vorige post hebben gedaan toen we de parameter notUsed
toevoegden. U kunt hier hetzelfde doen voor de [HttpPost] Delete
methode:
// POST: Movies/Delete/6
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Delete(int id, bool notUsed)
Publiceren naar Azure
Zie Zelfstudie: Een ASP.NET Core- en SQL Database-app bouwen in Azure App Servicevoor meer informatie over het implementeren in Azure.
Open de filmcontroller en bekijk de methode Details
:
// GET: Movies/Details/5
public async Task<IActionResult> Details(int? id)
{
if (id == null)
{
return NotFound();
}
var movie = await _context.Movie
.FirstOrDefaultAsync(m => m.Id == id);
if (movie == null)
{
return NotFound();
}
return View(movie);
}
De MVC-scaffolding-engine die deze actiemethode heeft gemaakt, voegt een opmerking toe met een HTTP-aanvraag die de methode aanroept. In dit geval is het een GET-aanvraag met drie URL-segmenten, de Movies
controller, de Details
methode en een id
waarde. Zoals u weet, worden deze segmenten gedefinieerd in Startup.cs
.
app.UseEndpoints(endpoints =>
{
endpoints.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
});
MET EF kunt u eenvoudig zoeken naar gegevens met behulp van de methode FirstOrDefaultAsync
. Een belangrijke beveiligingsfunctie die is ingebouwd in de methode, is dat de code controleert of de zoekmethode een film heeft gevonden voordat er iets mee wordt geprobeerd te doen. Een hacker kan bijvoorbeeld fouten in de site veroorzaken door de URL te wijzigen die is gemaakt door de koppelingen van http://localhost:{PORT}/Movies/Details/1
naar iets zoals http://localhost:{PORT}/Movies/Details/12345
(of een andere waarde die geen echte film vertegenwoordigt). Als u niet hebt gecontroleerd op een null-film, genereert de app een uitzondering.
Bekijk de methoden Delete
en DeleteConfirmed
.
// GET: Movies/Delete/5
public async Task<IActionResult> Delete(int? id)
{
if (id == null)
{
return NotFound();
}
var movie = await _context.Movie
.FirstOrDefaultAsync(m => m.Id == id);
if (movie == null)
{
return NotFound();
}
return View(movie);
}
// POST: Movies/Delete/5
[HttpPost, ActionName("Delete")]
[ValidateAntiForgeryToken]
public async Task<IActionResult> DeleteConfirmed(int id)
{
var movie = await _context.Movie.FindAsync(id);
_context.Movie.Remove(movie);
await _context.SaveChangesAsync();
return RedirectToAction(nameof(Index));
}
Houd er rekening mee dat de HTTP GET Delete
-methode de opgegeven film niet verwijdert. Het retourneert een weergave van de film waarin u de verwijdering kunt verzenden (HttpPost). Als u een verwijderingsbewerking uitvoert als reactie op een GET-aanvraag (of als u een bewerking uitvoert, een bewerking maakt of een andere bewerking waarmee gegevens worden gewijzigd), wordt er een beveiligingsgat geopend.
De [HttpPost]
methode waarmee de gegevens worden verwijderd, heet DeleteConfirmed
om de HTTP POST-methode een unieke handtekening of naam te geven. De twee methodesignaturen worden hieronder weergegeven.
// GET: Movies/Delete/5
public async Task<IActionResult> Delete(int? id)
{
// POST: Movies/Delete/5
[HttpPost, ActionName("Delete")]
[ValidateAntiForgeryToken]
public async Task<IActionResult> DeleteConfirmed(int id)
{
Voor de Common Language Runtime (CLR) moeten overbelaste methoden een unieke parameterhandtekening hebben (dezelfde methodenaam maar een andere lijst met parameters). Hier hebt u echter twee Delete
methoden nodig, één voor GET en één voor POST, die beide dezelfde parameterhandtekening hebben. (Beide moeten één geheel getal als parameter accepteren.)
Er zijn twee benaderingen voor dit probleem: u kunt de methoden verschillende namen geven. Dat is wat het steigeringsmechanisme in het voorgaande voorbeeld heeft gedaan. Dit introduceert echter een klein probleem: ASP.NET segmenten van een URL toewijzen aan actiemethoden op naam en als u de naam van een methode wijzigt, kan routering die methode normaal gesproken niet vinden. De oplossing is wat u in het voorbeeld ziet. Dit is het toevoegen van het kenmerk ActionName("Delete")
aan de methode DeleteConfirmed
. Dit kenmerk voert toewijzingen uit voor het routeringssysteem, zodat een URL die /Delete/ voor een POST-aanvraag bevat, de DeleteConfirmed
methode vindt.
Een andere veelgebruikte oplossing voor methoden met identieke namen en handtekeningen is het kunstmatig wijzigen van de handtekening van de POST-methode om een extra (ongebruikte) parameter op te nemen. Dat is wat we in een vorige post hebben gedaan toen we de parameter notUsed
toevoegden. U kunt hier hetzelfde doen voor de [HttpPost] Delete
methode:
// POST: Movies/Delete/6
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Delete(int id, bool notUsed)
Publiceren naar Azure
Zie Zelfstudie: Een ASP.NET Core- en SQL Database-app bouwen in Azure App Servicevoor meer informatie over het implementeren in Azure.