Escolha uma Página
(Last Updated On: 27/06/2018)

Os controladores (controllers) do Core MVC do ASP.NET podem retornar resultados formatados usando visualizadores (views)

O que são Views (Visualizadores)?


No padrão Model-View-Controller (MVC), o visualizador (view) encapsula os detalhes da apresentação da interação do usuário com o aplicativo. As visualizações são modelos HTML, com código “embutido”, que geram conteúdo para enviar ao cliente.

As visualizações usam a sintaxe chamada Razor, que permite que o código interaja com HTML com um mínimo de código.

As visualizações do ASP.NET Core MVC são arquivos .cshtml armazenados por padrão em uma pasta Views no aplicativo. Estas Views estão intimamente ligadas à pasta Controllers (controladores). Haverá um arquivo de controle para controlar as visualizações se cada sub-pasta em Views. O arquivo de controle contém ao menos uma ação para cada View estabelecida. Tipicamente o arquivo de controle (controller) tem ações para adicionar dados, visualizar somente, editar, apagar, listar, etc. E existe sempre uma visualização (view) correspondente a cada ação.

Abaixo, por exemplo, a sub-pasta Home Contém visualizadores para a página principal (index) e páginas de Contato (contact) e Sobre Nós (about).

Pasta de views (visualizadores)Na sub-pasta “Shared”  são definidas views especiais, com ações muito específicas: Views  parciais (Partial Views), Layouts e outros arquivos especiais que ajudam a reduzir repetição de código e permitem sua reutilização em diversas Views das demais Sub-pastas.


Benefícios de usar Views (visualizadores)

Os visualizadores ajudam a separar suas preocupações dentro de um aplicativo MVC. Eles encapsulam o nível de interface do usuário, separando-o da lógica de negócios (que é feita pelos controllers). As visualizações do ASP.NET MVC usam a sintaxe do Razor para tornar indolor a troca entre o código HTML e a lógica de dados no lado do servidor. Os aspectos comuns e repetitivos da interface do usuário do aplicativo podem ser facilmente reutilizados entre visualizações usando layout e diretivas compartilhadas ou visualizações parciais.


Criando uma View

As visualizações específicas de um controlador são criadas na sub-pasta Views/ [Nome do controlador].

As visualizações que são compartilhadas entre os controladores são colocadas na sub-pasta Views / Shared.

Muito importante: nomeie o arquivo de exibição o mesmo nome que a ação do controlador associado – e adicione a extensão de arquivo .cshtml.

Por exemplo, para criar uma visualização para a ação Sobre Nós  (About) no controlador Home, você criaria o arquivo About.cshtml na pasta / Views / Home. Um arquivo de exibição de exemplo (About.cshtml):

@{
    ViewData["Title"] = "About";
}
<h2>@ViewData["Title"].</h2>
<h3>@ViewData["Message"]</h3>

<p>Use this area to provide additional information.</p>

O código Razor é  sempre precedido pelo símbolo @.

As instruções C # são executadas dentro dos blocos de código Razor são sempre configuradas por chaves ({}), como a atribuição de “About” ao elemento ViewData [“Título”] mostrado acima.

O Razor pode ser usado para exibir valores dentro do HTML simplesmente fazendo referência ao valor com o símbolo @, conforme mostrado nos elementos <h2> e <h3> acima.

Esta View se concentra apenas na parte da saída para a qual é responsável. O resto do layout da página, e outros aspectos comuns à visualização, são especificados em outro lugar. Conheça mais detalhes lendo sobre o layout e a lógica de exibição compartilhada.


Como os Controladores (controllers) especificam os Visualizadores (Views)?

As visualizações geralmente são retornadas de ações como ViewResult. Seu método de ação pode criar e retornar um ViewResult diretamente, mas, mais comumente, se seu controlador herda do Controller, você simplesmente usará o método View helper (um simples View()), como demonstra esse exemplo: HomeController.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;

namespace WebApplication1.Controllers
{
    public class HomeController : Controller
    {
        public IActionResult Index()
        {
            return View();
        }

        public IActionResult About()
        {
            ViewData["Message"] = "Página de descrição da aplicação.";

            return View();
        }

        public IActionResult Contact()
        {
            ViewData["Message"] = "Página de Contato.";

            return View();
        }

        public IActionResult Error()
        {
            return View();
        }
    }
}

O método View() possui várias sobrecargas (overloads) para tornar as visualizações retornáveis mais fáceis para desenvolvedores de aplicativos. Você pode opcionalmente especificar uma visualização para retornar, bem como um objeto “modelo” para passar para a view. (no Visual Studio, clicando em View e pressionando F12, você tem acesso a todos os possíveis overloads. Isso vale para qualquer objeto, comando, etc… Não é perfeito mas ajuda muito).

Quando essa ação retorna, a exibição About.cshtml mostrada acima é renderizada:

página about

 

 

 

 


Onde está a View??? Descobrindo onde está!

Quando uma ação retorna uma visualização, ocorre um processo chamado de descoberta de visualização.

Esse processo determina qual arquivo de exibição será usado. A menos que um arquivo de exibição específico seja determinado, o CORE MVC procura primeiro uma visão específica do controlador. Se não encontrou, em seguida procura o nome da exibição correspondente numa pasta Compartilhada.

Muito Importante: Quando uma ação retorna o método View, como assim, Return View () ;, o nome da ação é usado como o nome da exibição.

Por exemplo, se isso fosse chamado a partir de um método de ação chamado “Index”, seria equivalente a passar um nome de exibição chamado “Index”.

Um nome de exibição pode ser explicitamente passado para o método (return View (“SomeView”);). Em ambos os casos, a pesquisa de views percorre o seguinte caminho:

  1. Views//. Cshtml
  2. Views / Shared / .cshtml

[! DICA] Recomendamos seguir a convenção de simplesmente retornar View () das ações sempre que possível, pois resulta em um código mais flexível e mais fácil de reutilizar.

Você pode especificar um path (um caminho do arquivo de exibição), em vez de simplesmente o nome do visualizador. Nesse caso, a extensão .cshtml deve ser especificada como parte do caminho do arquivo.

O caminho (path) deve ser relativo à raiz da aplicação (e, opcionalmente, pode começar com “/” ou “~ /”). Por exemplo: return View (“Views/Home/About.cshtml”);

[! NOTA] As visualizações parciais e os componentes de exibição (view components) usam mecanismos de descoberta semelhantes (mas não idênticos).[! NOTA] Você pode personalizar a convenção padrão sobre onde as visualizações estão localizadas no aplicativo usando um IViewLocationExpander personalizado.[! DICA] Os nomes de exibição podem ser sensíveis a maiúsculas e minúsculas, dependendo do sistema de arquivos do sistema operacional. Para compatibilidade em todos os sistemas operacionais, combine sempre as maiúsculas e minúsculas entre o nome do controlador e a ação, bem como o nome das pastas e nomes de arquivos associados.


Passando dados para as Views (visualizadores)

Você pode passar dados para visualizações usando vários mecanismos.

A abordagem mais robusta é especificar um tipo de modelo na visualização (comumente referido como um modelo de exibição, para distingui-lo de outros tipos de modelo de domínio do negócio) e, em seguida, passar uma instância desse tipo para o visualizador da ação.

Recomenda-se que você use sempre use um modelo ou modelo de exibição para passar dados para uma exibição. Isso permite que o visualizador aproveite, de maneira muito forte, a verificação dos dados (contidas já na definição do modelo). No arquivo de visualização, você pode especificar um modelo para uma visualização sempre usando a diretiva @model:

@model WebApplication1.ViewModels.Address
   <h2>Contato</h2>
   <address>
       @Model.Rua<br />
       @Model.Cidade, @Model.Estado @Model.CodigoPostal<br />
       <abbr title="Telefone">P:</abbr>
       11.555.0100
   </address>

Uma vez que um modelo foi especificado para um visualizador, a instância enviada para a exibição pode ser acessada de forma fortemente tipada, usando @Model como mostrado acima. Para fornecer uma instância do tipo de modelo para o visualizador, o controlador passa os dados como se fosse um parâmetro:

public IActionResult Contact()
   {
       ViewData["Message"] = "Sua página de Contato.";

       var viewModel = new Address()
       {
           Nome= "Microsoft",
           Rua= "One Microsoft Way",
           Cidade= "Redmond",
           Estado= "WA",
           CodigoPostal= "98052-6399"
       };
       return View(viewModel);
   }

Não há restrições sobre os tipos que podem ser fornecidos a uma visualização como um modelo. Recomenda-se passar modelos de visualização Plain Old CLR Objects (POCO), com pouco ou nenhum comportamento. Assim, a lógica de negócios pode ser encapsulada em outro lugar no aplicativo. Um exemplo dessa abordagem é o modelo de exibição de endereço usado no exemplo acima:

namespace WebApplication1.ViewModels
   {
       public class Address
       {
           public string Nome { get; set; }
           public string Rua { get; set; }
           public string Cidade { get; set; }
           public string Estado { get; set; }
           public string CodigoPostal { get; set; }
       }
   }

[! NOTA] Nada impede que você use as mesmas classes que seus tipos de modelo de negócios e seus tipos de modelo de exibição. No entanto, mantê-los separados permite que suas visualizações variem independentemente do seu modelo de domínio ou modelo de persistência. Isso também pode oferecer alguns benefícios de segurança (para os modelos em que os usuários enviarão dados ao aplicativo usando o modelo).

Loosely Typed Data (Dados não necessariamente em banco de dados)

Além das visualizações fortemente consistidas na digitação ou oriundas de bases de dados digitadas, todas as Views (visualizadores)  têm acesso a coleções de dados mais, digamos assim, livres. Qualquer coleção pode ser referenciada através de propriedades como ViewData ou ViewBag, tanto nos Controllers (controladores) como nas Views (visualizadores).

ViewBag e ViewData

A propriedade ViewBag é uma espécie de “empacotador de dados” em torno do ViewData que fornece uma visão dinâmica sobre de uma determinada coleção. Não é uma coleção separada.

ViewData é um objeto do dicionário, acessado através de chaves tipo string.

Você pode armazenar e recuperar objetos nele. O que você precisará lançá-los para um tipo específico quando for  extrair os dados.

Você pode usar ViewData para passar dados de um controlador para um visualizador. E também pode usá-los onde quiser dentro dos visualizadores (views – mesmo visualizações parciais e layouts). Dados tipo “string” podem ser armazenados e usados diretamente, sem a necessidade de “transmití-los” do Controller para  a View.

Definindo alguns valores para ViewData dentro de uma ação de um controller

public IActionResult NomeDaAcao()
   {
       ViewData["Saudacao"] = "Alo!";
       ViewData["Endereco"]  = new Endereco()
       {
           Nome = "Estevan",
           Rua = "Julio Paiva 1050",
           Cidade = "Valinhos",
           Estado = "SP",
           CodigoPostal = "13236-025"
       };

       return View();
   }

Trabalhando com os dados de uma ViewData em uma View

@{
       // Requisita a transmissão do controller para a View
       var endereco = ViewData["Endereco"] as Endereco;
   }

   @ViewData["Saudacao"], Mundo cruel!

   <endereco>
       @endereco.Nome<br />
       @endereco.Ruat<br />
       @endereco.Cidade, @aendereco.Estado - CEP: @endereco.CodigoPostal
   </endereco>

Já os objetos ViewBag fornecem acesso dinâmico aos objetos armazenados no ViewData. Isso pode ser mais conveniente para se trabalhar, uma vez que não requer o passo da transmissão para o visualizador (View).

Veja o mesmo exemplo acima, usando ViewBag em vez de uma instância de endereço dentro do View:

@ViewBag.Saudacao , Mundo Cruel

   <endereco>
       @ViewBag.Endereco.Nome<br />
       @ViewBag.Endereco.Rua<br />
       @ViewBag.Endereco.Cidade, @ViewBag.Endereco.Estado - CEP:  @ViewBag.Endereco.CodigoPostal
   </endereco>

[! NOTA] Uma vez que ambos se referem à mesma coleção ViewData subjacente, você pode misturar e combinar entre ViewData e ViewBag ao ler e escrever valores, se conveniente

Visualizações Dinâmicas (Dynamic Views)

São visualizações que não declaram um tipo de modelo, mas que possuem uma instância modelo passada para elas, de forma dinâmica. Por exemplo, se uma instância de Endereço é passada para uma visão que não declara um @model (no topo do arquivo de visualização), a visualização (view) ainda poderá se referir às propriedades da instância, como é mostrado a seguir:

   <endereco>
       @Model.Rua<br />
       @Model.Cidade, @Model.Estado @Model.CodigoPostal<br />
       <abbr title="Telefone">Fone:</abbr>
       19 9555.0100
   </endereco>

Esse recurso pode oferecer alguma flexibilidade, mas não oferece proteção de compilação ou mesmo o apoio do IntelliSense, dificultando a escrita do código Razor. Se a propriedade não existir, a página falhará no tempo de execução, obrigando você a voltar e corrigí-la.


Mais Recursos para as Visualizações (Views)

Os Tag Helpers (ajudantes de tags) facilitam a adição de comportamentos, do lado do servidor, às tags HTML existentes, evitando a necessidade de usar códigos personalizados ou ajudantes nas visualizações.

Os Tag Helpers são ajudantes que são aplicados como se fossem simples atributos de elementos HTML, que são ignorados por editores que não estão familiarizados com eles, permitindo que a marcação de exibição seja editada e renderizada em uma variedade de ferramentas.

Os Tag Helpers têm muitos usos e, em particular, podem tornar muito mais fácil o trabalho com formulários.

A geração de marcação HTML personalizada pode ser alcançada com muitos HTML Helpers já existentes. Mais que isso, é possível construir novos TAG HELPERS, embutindo-os na aplicação. Esses Tag Hepers podem ter seus próprios requisitos em termos de dados, permitido uma interface de usuário (UI) mais complexa, que fica encapsulada nos componentes das VIews (View Compnents).

Os componentes das views tem a mesma separação de preocupações que os controladores e as visualizações oferecem e podem eliminar a necessidade criação de ações e visualizações com dados, para lidar com dados, por usarem elementos muito simples na interface de usuário (UI).

Como ocorre com muitos outros aspectos do ASP.NET Core, as Views suportam a injeção de dependência (dependency injection),  permitindo que os serviços sejam injetados nas visualizações.


Referências:

  1. Rendering HTML with views in ASP.NET Core MVC

 

Obrigado pela sua leitura. Continue visitando este blog e compartilhe artigos em sua rede de relacionamento. Por favor, se quiser, registre sugestões e comentários ao final da página.

Você quer ter uma franquia de hospedagem com tudo para marketing digital e faturamento recorrente?

franquia builderall business