Parte 10, examine os métodos Details e Delete de um aplicativo ASP.NET Core
Observação
Esta não é a versão mais recente deste artigo. Para a versão atual, consulte a versão .NET 9 deste artigo.
Advertência
Esta versão do ASP.NET Core não é mais suportada. Para obter mais informações, consulte a Política de suporte do .NET e .NET Core. Para a versão atual, consulte a versão .NET 9 deste artigo.
Importante
Estas informações referem-se a um produto de pré-lançamento que pode ser substancialmente modificado antes de ser lançado comercialmente. A Microsoft não oferece garantias, expressas ou implícitas, em relação às informações fornecidas aqui.
Para a versão atual, consulte a versão .NET 9 deste artigo.
Por Rick Anderson
Abra o controlador de filme e examine o método 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);
}
O mecanismo de scaffolding MVC que criou esse método de ação adiciona um comentário mostrando uma solicitação HTTP que invoca o método. Neste caso, é uma solicitação GET com três segmentos de URL, o controlador Movies
, o método Details
e um valor id
. Lembre-se de que esses segmentos são definidos em Program.cs
.
app.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
O EF facilita a pesquisa de dados usando o método FirstOrDefaultAsync
. Um recurso de segurança importante embutido no método é que o código verifica se o método de pesquisa encontrou um filme antes de tentar fazer qualquer coisa com ele. Por exemplo, um hacker pode introduzir erros no site alterando o URL criado pelos links de http://localhost:{PORT}/Movies/Details/1
para algo como http://localhost:{PORT}/Movies/Details/12345
(ou algum outro valor que não represente um filme real). Se você não verificasse se havia um filme nulo, o aplicativo lançaria uma exceção.
Examine os métodos Delete
e 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));
}
Observe que o método HTTP GET Delete
não exclui o filme especificado, ele retorna uma exibição do filme onde você pode enviar (HttpPost) a exclusão. Executar uma operação de exclusão em resposta a uma solicitação GET (ou executar uma operação de edição, operação de criação ou qualquer outra operação que altere dados) abre uma falha de segurança.
O método [HttpPost]
que exclui os dados é nomeado DeleteConfirmed
para dar ao método HTTP POST uma assinatura ou nome exclusivo. As duas assinaturas de método são mostradas abaixo:
// 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)
{
O Common Language Runtime (CLR) requer métodos sobrecarregados para ter uma assinatura de parâmetro exclusiva (mesmo nome de método, mas lista diferente de parâmetros). No entanto, aqui você precisa de dois métodos Delete
-- um para GET e outro para POST -- que tenham a mesma assinatura de parâmetro. (Ambos precisam aceitar um único inteiro como parâmetro.)
Existem duas abordagens para este problema, uma é dar aos métodos nomes diferentes. Foi o que o mecanismo de andaimes fez no exemplo anterior. No entanto, isso introduz um pequeno problema: ASP.NET mapeia segmentos de uma URL para métodos de ação pelo nome e, se você renomear um método, o roteamento normalmente não seria capaz de encontrar esse método. A solução é o que você vê no exemplo, que é adicionar o atributo ActionName("Delete")
ao método DeleteConfirmed
. Esse atributo executa o mapeamento para o sistema de roteamento para que uma URL que inclua /Delete/ para uma solicitação POST encontre o método DeleteConfirmed
.
Outra solução comum para métodos que têm nomes e assinaturas idênticos é alterar artificialmente a assinatura do método POST para incluir um parâmetro extra (não utilizado). Foi o que fizemos em um post anterior quando adicionamos o parâmetro notUsed
. Você pode fazer a mesma coisa aqui para o método [HttpPost] Delete
:
// POST: Movies/Delete/6
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Delete(int id, bool notUsed)
Publicar no Azure
Para obter informações sobre como implantar no Azure, consulte Tutorial: Criar um aplicativo ASP.NET Core e Banco de Dados SQL no Serviço de Aplicativo do Azure.
Padrões confiáveis de aplicativos Web
Consulte The Reliable Web App Pattern for .NETvídeos do YouTube e o artigo para obter orientações sobre como criar uma aplicação ASP.NET Core moderna, fiável, com elevado desempenho, testável, económica e escalável, seja do zero ou refatorando uma aplicação existente.
Abra o controlador de filme e examine o método 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);
}
O mecanismo de scaffolding MVC que criou esse método de ação adiciona um comentário mostrando uma solicitação HTTP que invoca o método. Neste caso, é uma solicitação GET com três segmentos de URL, o controlador Movies
, o método Details
e um valor id
. Lembre-se de que esses segmentos são definidos em Program.cs
.
app.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
O EF facilita a pesquisa de dados usando o método FirstOrDefaultAsync
. Um recurso de segurança importante embutido no método é que o código verifica se o método de pesquisa encontrou um filme antes de tentar fazer qualquer coisa com ele. Por exemplo, um hacker pode introduzir erros no site alterando o URL criado pelos links de http://localhost:{PORT}/Movies/Details/1
para algo como http://localhost:{PORT}/Movies/Details/12345
(ou algum outro valor que não represente um filme real). Se você não verificasse se havia um filme nulo, o aplicativo lançaria uma exceção.
Examine os métodos Delete
e 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));
}
Observe que o método HTTP GET Delete
não exclui o filme especificado, ele retorna uma exibição do filme onde você pode enviar (HttpPost) a exclusão. Executar uma operação de exclusão em resposta a uma solicitação GET (ou executar uma operação de edição, operação de criação ou qualquer outra operação que altere dados) abre uma falha de segurança.
O método [HttpPost]
que exclui os dados é nomeado DeleteConfirmed
para dar ao método HTTP POST uma assinatura ou nome exclusivo. As duas assinaturas de método são mostradas abaixo:
// 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)
{
O Common Language Runtime (CLR) requer métodos sobrecarregados para ter uma assinatura de parâmetro exclusiva (mesmo nome de método, mas lista diferente de parâmetros). No entanto, aqui você precisa de dois métodos Delete
-- um para GET e outro para POST -- que tenham a mesma assinatura de parâmetro. (Ambos precisam aceitar um único inteiro como parâmetro.)
Existem duas abordagens para este problema, uma é dar aos métodos nomes diferentes. Foi o que o mecanismo de andaimes fez no exemplo anterior. No entanto, isso introduz um pequeno problema: ASP.NET mapeia segmentos de uma URL para métodos de ação pelo nome e, se você renomear um método, o roteamento normalmente não seria capaz de encontrar esse método. A solução é o que você vê no exemplo, que é adicionar o atributo ActionName("Delete")
ao método DeleteConfirmed
. Esse atributo executa o mapeamento para o sistema de roteamento para que uma URL que inclua /Delete/ para uma solicitação POST encontre o método DeleteConfirmed
.
Outra solução comum para métodos que têm nomes e assinaturas idênticos é alterar artificialmente a assinatura do método POST para incluir um parâmetro extra (não utilizado). Foi o que fizemos em um post anterior quando adicionamos o parâmetro notUsed
. Você pode fazer a mesma coisa aqui para o método [HttpPost] Delete
:
// POST: Movies/Delete/6
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Delete(int id, bool notUsed)
Publicar no Azure
Para obter informações sobre como implantar no Azure, consulte Tutorial: Criar um aplicativo ASP.NET Core e Banco de Dados SQL no Serviço de Aplicativo do Azure.
Padrões confiáveis de aplicativos Web
Consulte The Reliable Web App Pattern for .NETvídeos do YouTube e o artigo para obter orientações sobre como criar uma aplicação ASP.NET Core moderna, fiável, com elevado desempenho, testável, económica e escalável, seja do zero ou refatorando uma aplicação existente.
Abra o controlador de filme e examine o método 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);
}
O mecanismo de scaffolding MVC que criou esse método de ação adiciona um comentário mostrando uma solicitação HTTP que invoca o método. Neste caso, é uma solicitação GET com três segmentos de URL, o controlador Movies
, o método Details
e um valor id
. Lembre-se de que esses segmentos são definidos em Program.cs
.
app.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
O EF facilita a pesquisa de dados usando o método FirstOrDefaultAsync
. Um recurso de segurança importante embutido no método é que o código verifica se o método de pesquisa encontrou um filme antes de tentar fazer qualquer coisa com ele. Por exemplo, um hacker pode introduzir erros no site alterando o URL criado pelos links de http://localhost:{PORT}/Movies/Details/1
para algo como http://localhost:{PORT}/Movies/Details/12345
(ou algum outro valor que não represente um filme real). Se você não verificasse se havia um filme nulo, o aplicativo lançaria uma exceção.
Examine os métodos Delete
e 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));
}
Observe que o método HTTP GET Delete
não exclui o filme especificado, ele retorna uma exibição do filme onde você pode enviar (HttpPost) a exclusão. Executar uma operação de exclusão em resposta a uma solicitação GET (ou executar uma operação de edição, operação de criação ou qualquer outra operação que altere dados) abre uma falha de segurança.
O método [HttpPost]
que exclui os dados é nomeado DeleteConfirmed
para dar ao método HTTP POST uma assinatura ou nome exclusivo. As duas assinaturas de método são mostradas abaixo:
// 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)
{
O Common Language Runtime (CLR) requer métodos sobrecarregados para ter uma assinatura de parâmetro exclusiva (mesmo nome de método, mas lista diferente de parâmetros). No entanto, aqui você precisa de dois métodos Delete
-- um para GET e outro para POST -- que tenham a mesma assinatura de parâmetro. (Ambos precisam aceitar um único inteiro como parâmetro.)
Existem duas abordagens para este problema, uma é dar aos métodos nomes diferentes. Foi o que o mecanismo de andaimes fez no exemplo anterior. No entanto, isso introduz um pequeno problema: ASP.NET mapeia segmentos de uma URL para métodos de ação pelo nome e, se você renomear um método, o roteamento normalmente não seria capaz de encontrar esse método. A solução é o que você vê no exemplo, que é adicionar o atributo ActionName("Delete")
ao método DeleteConfirmed
. Esse atributo executa o mapeamento para o sistema de roteamento para que uma URL que inclua /Delete/ para uma solicitação POST encontre o método DeleteConfirmed
.
Outra solução comum para métodos que têm nomes e assinaturas idênticos é alterar artificialmente a assinatura do método POST para incluir um parâmetro extra (não utilizado). Foi o que fizemos em um post anterior quando adicionamos o parâmetro notUsed
. Você pode fazer a mesma coisa aqui para o método [HttpPost] Delete
:
// POST: Movies/Delete/6
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Delete(int id, bool notUsed)
Publicar no Azure
Para obter informações sobre como implantar no Azure, consulte Tutorial: Criar um aplicativo ASP.NET Core e Banco de Dados SQL no Serviço de Aplicativo do Azure.
Abra o controlador de filme e examine o método 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);
}
O mecanismo de scaffolding MVC que criou esse método de ação adiciona um comentário mostrando uma solicitação HTTP que invoca o método. Neste caso, é uma solicitação GET com três segmentos de URL, o controlador Movies
, o método Details
e um valor id
. Lembre-se de que esses segmentos são definidos em Program.cs
.
app.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
O EF facilita a pesquisa de dados usando o método FirstOrDefaultAsync
. Um recurso de segurança importante embutido no método é que o código verifica se o método de pesquisa encontrou um filme antes de tentar fazer qualquer coisa com ele. Por exemplo, um hacker pode introduzir erros no site alterando o URL criado pelos links de http://localhost:{PORT}/Movies/Details/1
para algo como http://localhost:{PORT}/Movies/Details/12345
(ou algum outro valor que não represente um filme real). Se você não verificasse se havia um filme nulo, o aplicativo lançaria uma exceção.
Examine os métodos Delete
e 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));
}
Observe que o método HTTP GET Delete
não exclui o filme especificado, ele retorna uma exibição do filme onde você pode enviar (HttpPost) a exclusão. Executar uma operação de exclusão em resposta a uma solicitação GET (ou executar uma operação de edição, operação de criação ou qualquer outra operação que altere dados) abre uma falha de segurança.
O método [HttpPost]
que exclui os dados é nomeado DeleteConfirmed
para dar ao método HTTP POST uma assinatura ou nome exclusivo. As duas assinaturas de método são mostradas abaixo:
// 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)
{
O Common Language Runtime (CLR) requer métodos sobrecarregados para ter uma assinatura de parâmetro exclusiva (mesmo nome de método, mas lista diferente de parâmetros). No entanto, aqui você precisa de dois métodos Delete
-- um para GET e outro para POST -- que tenham a mesma assinatura de parâmetro. (Ambos precisam aceitar um único inteiro como parâmetro.)
Existem duas abordagens para este problema, uma é dar aos métodos nomes diferentes. Foi o que o mecanismo de andaimes fez no exemplo anterior. No entanto, isso introduz um pequeno problema: ASP.NET mapeia segmentos de uma URL para métodos de ação pelo nome e, se você renomear um método, o roteamento normalmente não seria capaz de encontrar esse método. A solução é o que você vê no exemplo, que é adicionar o atributo ActionName("Delete")
ao método DeleteConfirmed
. Esse atributo executa o mapeamento para o sistema de roteamento para que uma URL que inclua /Delete/ para uma solicitação POST encontre o método DeleteConfirmed
.
Outra solução comum para métodos que têm nomes e assinaturas idênticos é alterar artificialmente a assinatura do método POST para incluir um parâmetro extra (não utilizado). Foi o que fizemos em um post anterior quando adicionamos o parâmetro notUsed
. Você pode fazer a mesma coisa aqui para o método [HttpPost] Delete
:
// POST: Movies/Delete/6
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Delete(int id, bool notUsed)
Publicar no Azure
Para obter informações sobre como implantar no Azure, consulte Tutorial: Criar um aplicativo ASP.NET Core e Banco de Dados SQL no Serviço de Aplicativo do Azure.
Abra o controlador de filme e examine o método 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);
}
O mecanismo de scaffolding MVC que criou esse método de ação adiciona um comentário mostrando uma solicitação HTTP que invoca o método. Neste caso, é uma solicitação GET com três segmentos de URL, o controlador Movies
, o método Details
e um valor id
. Lembre-se de que esses segmentos são definidos em Startup.cs
.
app.UseEndpoints(endpoints =>
{
endpoints.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
});
O EF facilita a pesquisa de dados usando o método FirstOrDefaultAsync
. Um recurso de segurança importante embutido no método é que o código verifica se o método de pesquisa encontrou um filme antes de tentar fazer qualquer coisa com ele. Por exemplo, um hacker pode introduzir erros no site alterando o URL criado pelos links de http://localhost:{PORT}/Movies/Details/1
para algo como http://localhost:{PORT}/Movies/Details/12345
(ou algum outro valor que não represente um filme real). Se você não verificasse se havia um filme nulo, o aplicativo lançaria uma exceção.
Examine os métodos Delete
e 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));
}
Observe que o método HTTP GET Delete
não exclui o filme especificado, ele retorna uma exibição do filme onde você pode enviar (HttpPost) a exclusão. Executar uma operação de exclusão em resposta a uma solicitação GET (ou executar uma operação de edição, operação de criação ou qualquer outra operação que altere dados) abre uma falha de segurança.
O método [HttpPost]
que exclui os dados é nomeado DeleteConfirmed
para dar ao método HTTP POST uma assinatura ou nome exclusivo. As duas assinaturas de método são mostradas abaixo:
// 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)
{
O Common Language Runtime (CLR) requer métodos sobrecarregados para ter uma assinatura de parâmetro exclusiva (mesmo nome de método, mas lista diferente de parâmetros). No entanto, aqui você precisa de dois métodos Delete
-- um para GET e outro para POST -- que tenham a mesma assinatura de parâmetro. (Ambos precisam aceitar um único inteiro como parâmetro.)
Existem duas abordagens para este problema, uma é dar aos métodos nomes diferentes. Foi o que o mecanismo de andaimes fez no exemplo anterior. No entanto, isso introduz um pequeno problema: ASP.NET mapeia segmentos de uma URL para métodos de ação pelo nome e, se você renomear um método, o roteamento normalmente não seria capaz de encontrar esse método. A solução é o que você vê no exemplo, que é adicionar o atributo ActionName("Delete")
ao método DeleteConfirmed
. Esse atributo executa o mapeamento para o sistema de roteamento para que uma URL que inclua /Delete/ para uma solicitação POST encontre o método DeleteConfirmed
.
Outra solução comum para métodos que têm nomes e assinaturas idênticos é alterar artificialmente a assinatura do método POST para incluir um parâmetro extra (não utilizado). Foi o que fizemos em um post anterior quando adicionamos o parâmetro notUsed
. Você pode fazer a mesma coisa aqui para o método [HttpPost] Delete
:
// POST: Movies/Delete/6
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Delete(int id, bool notUsed)
Publicar no Azure
Para obter informações sobre como implantar no Azure, consulte Tutorial: Criar um aplicativo ASP.NET Core e Banco de Dados SQL no Serviço de Aplicativo do Azure.