Neste artigo eu vou mostrar como criar uma aplicação ASP .NET Core MVC usando o VS 2017.

Continuando a nona parte do artigo  vamos analisar o aplicativo e fazer algumas melhorias nos métodos Details e Delete gerados automaticamente.

Este artigo conclui esta introdução básica ao ASP .NET Core.

Examinando o método Details

Vamos abrir o arquivo FilmesController.cs na pasta Controllers e examinar o método Details:

        // GET: Filmes/Details/5
        public async Task<IActionResult> Details(int? id)
        {
            if (id == null)
            {
                return NotFound();
            }

            var filme = await _context.Filme
                            .SingleOrDefaultAsync(m => m.ID == id);

            if (filme == null)
            {
                return NotFound();
            }

            return View(filme);
        }

O mecanismo de Scaffolding MVC que criou este método Action adicionou 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 Filmes, o método Details e um valor id. Lembre que esses segmentos são definidos em no método Configure do arquivo Startup.cs:

     ...
     app.UseMvc(routes =>
     {
          routes.MapRoute( 
          name: "default",
          template: "{controller=Home}/{action=Index}/{id?}");
    });
   ...

O EF facilita a pesquisa dos dados usando o método SingleOrDefaultAsync. Um recurso de segurança importante deste método Details é 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 a URL criada pelos links de http://localhost:xxxx/Filmes/Details/1 para algo como http://localhost:xxxx/Filmes/Details/12345 ( Ou algum outro valor que não represente um filme real) com um objetivo de provocar um erro.

Se você não fosse feita a verificação de filme nulo, o aplicativo lançaria uma exceção.

Examinando o método Delete

Vejamos agora os métodos Delete e DeleteConfirm do controlador FilmesController:

        // GET: Filmes/Delete/5
        public async Task<IActionResult> Delete(int? id)
        {
            if (id == null)
            {
                return NotFound();
            }

            var filme = await _context.Filme
                            .SingleOrDefaultAsync(m => m.ID == id);

            if (filme == null)
            {
                return NotFound();
            }

            return View(filme);
        }

        // POST: Filmes/Delete/5
        [HttpPost, ActionName("Delete")]
        [ValidateAntiForgeryToken]
        public async Task<IActionResult> DeleteConfirmed(int id)
        {
            var filme = await _context.Filme.SingleOrDefaultAsync(m => m.ID == id);
                            _context.Filme.Remove(filme);

            await _context.SaveChangesAsync();
            return RedirectToAction("Index");
        }

Observe que o método HTTP GET Delete não exclui o filme especificado, ele retorna uma view do filme onde você pode submeter(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, ou criação ou qualquer outra operação que altera dados) abre um buraco de segurança.

O método [HttpPost] que exclui os dados tem o nome DeleteConfirmed para dar ao método HTTP POST uma assinatura ou nome exclusivo. As assinaturas de dois métodos são mostradas abaixo:

A Common Language Runtime (CLR) requer métodos sobrecarregados para ter uma assinatura de parâmetro exclusivo (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 - e ambos têm a mesma assinatura de parâmetro. (Ambos precisam aceitar um único inteiro como um parâmetro.)

Existem duas abordagens para este problema, uma delas é dar aos métodos nomes diferentes. Isso é o que o mecanismo Scaffolding fez no exemplo anterior. No entanto, isso introduz um pequeno problema: a ASP.NET mapeia segmentos de um URL para métodos Action por 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") para o método DeleteConfirmed.

Esse atributo realiza o mapeamento para o sistema de roteamento de modo que uma URL que inclui /Delete/ para uma solicitação POST irá encontrar o método DeleteConfirmed.

Outra solução para contornar o problema de métodos que têm nomes e assinaturas idênticas, é alterar artificialmente a assinatura do método POST para incluir um parâmetro extra (não utilizado). Isso é o que fizemos em um post anterior quando adicionamos o parâmetro notUsed. Você poderia fazer a mesma coisa aqui para o método [HttpPost] Delete:

// POST: Movies/Delete/6
[ValidateAntiForgeryToken]
public async Task<IActionResult> Delete(int id, bool notUsed)

E assim concluímos essa série de artigo apresentando os conceitos básicos da ASP .NET MVC Core.

Na verdade se você já conhecia a ASP .NET MVC  percebeu que a maioria dos conceitos sobre como a ASP .NET MVC funciona são utilizados com ASP .NET MVC Core.

Se você não conhece os fundamenteos da tecnologia ASP .NET MVC conheça o curso : CURSO ASP .NET MVC 5 Vídeo Aulas

Pegue o projeto aqui : MvcFilme.zip

E, como Moisés levantou a serpente no deserto, assim importa que o Filho do homem seja levantado;
Para que todo aquele que nele crê não pereça, mas tenha a vida eterna.
João 3:14,15

  Gostou ?   Compartilhe no Facebook   Compartilhe no Twitter

Referências:

• Seção VB .NET do Site Macoratti.net

• Super DVD .NET - A sua porta de entrada na plataforma .NET

• Super DVD Vídeo Aulas - Vídeo Aula sobre VB .NET, ASP .NET e C#

• Seção C# do site Macoratti.net

• Super DVD C#

• Super DVD Visual Basic

• Curso Básico VB .NET - Vídeo Aulas

• Curso C# Básico - Vídeo Aulas

• Padrões de Projeto - O modelo MVC - Macoratti.net

• ASP .NET - MVC - Introdução - Macoratti.net

• Criando uma aplicação MVC básica - Macoratti.net

• Seção ASP .NET MVC - Macoratti .NET

José Carlos Macoratti