Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Not
Det här är inte den senaste versionen av den här artikeln. Den aktuella versionen finns i .NET 10-versionen av den här artikeln.
Varning
Den här versionen av ASP.NET Core stöds inte längre. Mer information finns i .NET och .NET Core Support Policy. Den aktuella versionen finns i den .NET 9-versionen av den här artikeln.
Öppna filmkontrollanten och granska metoden 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);
}
MVC-byggnadsställningsmotorn som skapade den här åtgärdsmetoden lägger till en kommentar som visar en HTTP-begäran som anropar metoden. I det här fallet är det en GET-begäran med tre URL-segment, den Movies kontrollanten, metoden Details och ett id värde. Kom ihåg att dessa segment definieras i Program.cs.
app.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
EF gör det enkelt att söka efter data med hjälp av metoden FirstOrDefaultAsync. En viktig säkerhetsfunktion som är inbyggd i metoden är att koden verifierar att sökmetoden har hittat en film innan den försöker göra något med den. En hackare kan till exempel införa fel på webbplatsen genom att ändra url:en som skapas av länkarna från http://localhost:{PORT}/Movies/Details/1 till något som http://localhost:{PORT}/Movies/Details/12345 (eller något annat värde som inte representerar en faktisk film). Om du inte söker efter en null-film utlöser appen ett undantag.
Granska metoderna Delete och 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));
}
Observera att metoden HTTP GET Delete inte tar bort den angivna filmen. Den returnerar en vy över filmen där du kan skicka borttagningen (HttpPost). Om du utför en borttagningsåtgärd som svar på en GET-begäran (eller för den delen utför en redigeringsåtgärd, skapar en åtgärd eller någon annan åtgärd som ändrar data) öppnas ett säkerhetshål.
Den [HttpPost] metod som tar bort data heter DeleteConfirmed för att ge HTTP POST-metoden en unik signatur eller ett unikt namn. De två metodsignaturerna visas nedan:
// 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)
{
Clr (Common Language Runtime) kräver att överlagrade metoder har en unik parametersignatur (samma metodnamn men en annan lista med parametrar). Här behöver du dock två Delete metoder – en för GET och en för POST – som båda har samma parametersignatur. (Båda måste acceptera ett heltal som en parameter.)
Det finns två metoder för det här problemet, en är att ge metoderna olika namn. Det var vad mekanismen för byggnadsställningar gjorde i föregående exempel. Detta medför dock ett litet problem: ASP.NET mappar segment av en URL till åtgärdsmetoder efter namn, och om du byter namn på en metod skulle routning normalt inte kunna hitta den metoden. Lösningen är det du ser i exemplet, som är att lägga till attributet ActionName("Delete") i metoden DeleteConfirmed. Det attributet utför mappning för routningssystemet så att en URL som innehåller /Delete/ för en POST-begäran hittar DeleteConfirmed-metoden.
Ett annat vanligt arbete för metoder som har identiska namn och signaturer är att artificiellt ändra signaturen för POST-metoden så att den innehåller en extra parameter (oanvänd). Det gjorde vi i ett tidigare inlägg när vi lade till parametern notUsed. Du kan göra samma sak här för metoden [HttpPost] Delete:
// POST: Movies/Delete/6
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Delete(int id, bool notUsed)
Publicera till Azure
Information om hur du distribuerar till Azure finns i Självstudie: Skapa en ASP.NET Core- och SQL Database-app i Azure App Service.
Mönster för företagswebbappar
Vägledning om hur du skapar en tillförlitlig, säker, högpresterande, testbar och skalbar ASP.NET Core-app finns i Enterprise-webbappmönster. En komplett exempelwebbapp av produktionskvalitet som implementerar mönstren är tillgänglig.
Öppna filmkontrollanten och granska metoden 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);
}
MVC-byggnadsställningsmotorn som skapade den här åtgärdsmetoden lägger till en kommentar som visar en HTTP-begäran som anropar metoden. I det här fallet är det en GET-begäran med tre URL-segment, den Movies kontrollanten, metoden Details och ett id värde. Kom ihåg att dessa segment definieras i Program.cs.
app.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
EF gör det enkelt att söka efter data med hjälp av metoden FirstOrDefaultAsync. En viktig säkerhetsfunktion som är inbyggd i metoden är att koden verifierar att sökmetoden har hittat en film innan den försöker göra något med den. En hackare kan till exempel införa fel på webbplatsen genom att ändra url:en som skapas av länkarna från http://localhost:{PORT}/Movies/Details/1 till något som http://localhost:{PORT}/Movies/Details/12345 (eller något annat värde som inte representerar en faktisk film). Om du inte söker efter en null-film utlöser appen ett undantag.
Granska metoderna Delete och 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));
}
Observera att metoden HTTP GET Delete inte tar bort den angivna filmen. Den returnerar en vy över filmen där du kan skicka borttagningen (HttpPost). Om du utför en borttagningsåtgärd som svar på en GET-begäran (eller för den delen utför en redigeringsåtgärd, skapar en åtgärd eller någon annan åtgärd som ändrar data) öppnas ett säkerhetshål.
Den [HttpPost] metod som tar bort data heter DeleteConfirmed för att ge HTTP POST-metoden en unik signatur eller ett unikt namn. De två metodsignaturerna visas nedan:
// 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)
{
Clr (Common Language Runtime) kräver att överlagrade metoder har en unik parametersignatur (samma metodnamn men en annan lista med parametrar). Här behöver du dock två Delete metoder – en för GET och en för POST – som båda har samma parametersignatur. (Båda måste acceptera ett heltal som en parameter.)
Det finns två metoder för det här problemet, en är att ge metoderna olika namn. Det var vad mekanismen för byggnadsställningar gjorde i föregående exempel. Detta medför dock ett litet problem: ASP.NET mappar segment av en URL till åtgärdsmetoder efter namn, och om du byter namn på en metod skulle routning normalt inte kunna hitta den metoden. Lösningen är det du ser i exemplet, som är att lägga till attributet ActionName("Delete") i metoden DeleteConfirmed. Det attributet utför mappning för routningssystemet så att en URL som innehåller /Delete/ för en POST-begäran hittar DeleteConfirmed-metoden.
Ett annat vanligt arbete för metoder som har identiska namn och signaturer är att artificiellt ändra signaturen för POST-metoden så att den innehåller en extra parameter (oanvänd). Det gjorde vi i ett tidigare inlägg när vi lade till parametern notUsed. Du kan göra samma sak här för metoden [HttpPost] Delete:
// POST: Movies/Delete/6
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Delete(int id, bool notUsed)
Publicera till Azure
Information om hur du distribuerar till Azure finns i Självstudie: Skapa en ASP.NET Core- och SQL Database-app i Azure App Service.
Mönster för företagswebbappar
Vägledning om hur du skapar en tillförlitlig, säker, högpresterande, testbar och skalbar ASP.NET Core-app finns i Enterprise-webbappmönster. En komplett exempelwebbapp av produktionskvalitet som implementerar mönstren är tillgänglig.
Öppna filmkontrollanten och granska metoden 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);
}
MVC-byggnadsställningsmotorn som skapade den här åtgärdsmetoden lägger till en kommentar som visar en HTTP-begäran som anropar metoden. I det här fallet är det en GET-begäran med tre URL-segment, den Movies kontrollanten, metoden Details och ett id värde. Kom ihåg att dessa segment definieras i Program.cs.
app.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
EF gör det enkelt att söka efter data med hjälp av metoden FirstOrDefaultAsync. En viktig säkerhetsfunktion som är inbyggd i metoden är att koden verifierar att sökmetoden har hittat en film innan den försöker göra något med den. En hackare kan till exempel införa fel på webbplatsen genom att ändra url:en som skapas av länkarna från http://localhost:{PORT}/Movies/Details/1 till något som http://localhost:{PORT}/Movies/Details/12345 (eller något annat värde som inte representerar en faktisk film). Om du inte söker efter en null-film utlöser appen ett undantag.
Granska metoderna Delete och 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));
}
Observera att metoden HTTP GET Delete inte tar bort den angivna filmen. Den returnerar en vy över filmen där du kan skicka borttagningen (HttpPost). Om du utför en borttagningsåtgärd som svar på en GET-begäran (eller för den delen utför en redigeringsåtgärd, skapar en åtgärd eller någon annan åtgärd som ändrar data) öppnas ett säkerhetshål.
Den [HttpPost] metod som tar bort data heter DeleteConfirmed för att ge HTTP POST-metoden en unik signatur eller ett unikt namn. De två metodsignaturerna visas nedan:
// 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)
{
Clr (Common Language Runtime) kräver att överlagrade metoder har en unik parametersignatur (samma metodnamn men en annan lista med parametrar). Här behöver du dock två Delete metoder – en för GET och en för POST – som båda har samma parametersignatur. (Båda måste acceptera ett heltal som en parameter.)
Det finns två metoder för det här problemet, en är att ge metoderna olika namn. Det var vad mekanismen för byggnadsställningar gjorde i föregående exempel. Detta medför dock ett litet problem: ASP.NET mappar segment av en URL till åtgärdsmetoder efter namn, och om du byter namn på en metod skulle routning normalt inte kunna hitta den metoden. Lösningen är det du ser i exemplet, som är att lägga till attributet ActionName("Delete") i metoden DeleteConfirmed. Det attributet utför mappning för routningssystemet så att en URL som innehåller /Delete/ för en POST-begäran hittar DeleteConfirmed-metoden.
Ett annat vanligt arbete för metoder som har identiska namn och signaturer är att artificiellt ändra signaturen för POST-metoden så att den innehåller en extra parameter (oanvänd). Det gjorde vi i ett tidigare inlägg när vi lade till parametern notUsed. Du kan göra samma sak här för metoden [HttpPost] Delete:
// POST: Movies/Delete/6
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Delete(int id, bool notUsed)
Publicera till Azure
Information om hur du distribuerar till Azure finns i Självstudie: Skapa en ASP.NET Core- och SQL Database-app i Azure App Service.
Öppna filmkontrollanten och granska metoden 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);
}
MVC-byggnadsställningsmotorn som skapade den här åtgärdsmetoden lägger till en kommentar som visar en HTTP-begäran som anropar metoden. I det här fallet är det en GET-begäran med tre URL-segment, den Movies kontrollanten, metoden Details och ett id värde. Kom ihåg att dessa segment definieras i Program.cs.
app.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
EF gör det enkelt att söka efter data med hjälp av metoden FirstOrDefaultAsync. En viktig säkerhetsfunktion som är inbyggd i metoden är att koden verifierar att sökmetoden har hittat en film innan den försöker göra något med den. En hackare kan till exempel införa fel på webbplatsen genom att ändra url:en som skapas av länkarna från http://localhost:{PORT}/Movies/Details/1 till något som http://localhost:{PORT}/Movies/Details/12345 (eller något annat värde som inte representerar en faktisk film). Om du inte söker efter en null-film utlöser appen ett undantag.
Granska metoderna Delete och 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));
}
Observera att metoden HTTP GET Delete inte tar bort den angivna filmen. Den returnerar en vy över filmen där du kan skicka borttagningen (HttpPost). Om du utför en borttagningsåtgärd som svar på en GET-begäran (eller för den delen utför en redigeringsåtgärd, skapar en åtgärd eller någon annan åtgärd som ändrar data) öppnas ett säkerhetshål.
Den [HttpPost] metod som tar bort data heter DeleteConfirmed för att ge HTTP POST-metoden en unik signatur eller ett unikt namn. De två metodsignaturerna visas nedan:
// 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)
{
Clr (Common Language Runtime) kräver att överlagrade metoder har en unik parametersignatur (samma metodnamn men en annan lista med parametrar). Här behöver du dock två Delete metoder – en för GET och en för POST – som båda har samma parametersignatur. (Båda måste acceptera ett heltal som en parameter.)
Det finns två metoder för det här problemet, en är att ge metoderna olika namn. Det var vad mekanismen för byggnadsställningar gjorde i föregående exempel. Detta medför dock ett litet problem: ASP.NET mappar segment av en URL till åtgärdsmetoder efter namn, och om du byter namn på en metod skulle routning normalt inte kunna hitta den metoden. Lösningen är det du ser i exemplet, som är att lägga till attributet ActionName("Delete") i metoden DeleteConfirmed. Det attributet utför mappning för routningssystemet så att en URL som innehåller /Delete/ för en POST-begäran hittar DeleteConfirmed-metoden.
Ett annat vanligt arbete för metoder som har identiska namn och signaturer är att artificiellt ändra signaturen för POST-metoden så att den innehåller en extra parameter (oanvänd). Det gjorde vi i ett tidigare inlägg när vi lade till parametern notUsed. Du kan göra samma sak här för metoden [HttpPost] Delete:
// POST: Movies/Delete/6
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Delete(int id, bool notUsed)
Publicera till Azure
Information om hur du distribuerar till Azure finns i Självstudie: Skapa en ASP.NET Core- och SQL Database-app i Azure App Service.
Öppna filmkontrollanten och granska metoden 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);
}
MVC-byggnadsställningsmotorn som skapade den här åtgärdsmetoden lägger till en kommentar som visar en HTTP-begäran som anropar metoden. I det här fallet är det en GET-begäran med tre URL-segment, den Movies kontrollanten, metoden Details och ett id värde. Kom ihåg att dessa segment definieras i Startup.cs.
app.UseEndpoints(endpoints =>
{
endpoints.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
});
EF gör det enkelt att söka efter data med hjälp av metoden FirstOrDefaultAsync. En viktig säkerhetsfunktion som är inbyggd i metoden är att koden verifierar att sökmetoden har hittat en film innan den försöker göra något med den. En hackare kan till exempel införa fel på webbplatsen genom att ändra url:en som skapas av länkarna från http://localhost:{PORT}/Movies/Details/1 till något som http://localhost:{PORT}/Movies/Details/12345 (eller något annat värde som inte representerar en faktisk film). Om du inte söker efter en null-film utlöser appen ett undantag.
Granska metoderna Delete och 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));
}
Observera att metoden HTTP GET Delete inte tar bort den angivna filmen. Den returnerar en vy över filmen där du kan skicka borttagningen (HttpPost). Om du utför en borttagningsåtgärd som svar på en GET-begäran (eller för den delen utför en redigeringsåtgärd, skapar en åtgärd eller någon annan åtgärd som ändrar data) öppnas ett säkerhetshål.
Den [HttpPost] metod som tar bort data heter DeleteConfirmed för att ge HTTP POST-metoden en unik signatur eller ett unikt namn. De två metodsignaturerna visas nedan:
// 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)
{
Clr (Common Language Runtime) kräver att överlagrade metoder har en unik parametersignatur (samma metodnamn men en annan lista med parametrar). Här behöver du dock två Delete metoder – en för GET och en för POST – som båda har samma parametersignatur. (Båda måste acceptera ett heltal som en parameter.)
Det finns två metoder för det här problemet, en är att ge metoderna olika namn. Det var vad mekanismen för byggnadsställningar gjorde i föregående exempel. Detta medför dock ett litet problem: ASP.NET mappar segment av en URL till åtgärdsmetoder efter namn, och om du byter namn på en metod skulle routning normalt inte kunna hitta den metoden. Lösningen är det du ser i exemplet, som är att lägga till attributet ActionName("Delete") i metoden DeleteConfirmed. Det attributet utför mappning för routningssystemet så att en URL som innehåller /Delete/ för en POST-begäran hittar DeleteConfirmed-metoden.
Ett annat vanligt arbete för metoder som har identiska namn och signaturer är att artificiellt ändra signaturen för POST-metoden så att den innehåller en extra parameter (oanvänd). Det gjorde vi i ett tidigare inlägg när vi lade till parametern notUsed. Du kan göra samma sak här för metoden [HttpPost] Delete:
// POST: Movies/Delete/6
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Delete(int id, bool notUsed)
Publicera till Azure
Information om hur du distribuerar till Azure finns i Självstudie: Skapa en ASP.NET Core- och SQL Database-app i Azure App Service.
ASP.NET Core