Introdução ao ASP.NET MVC – Parte 3

Olá pessoal, voltando pra esta série de artigos após algum tempo e continuando de onde paramos no artigo anterior, neste vamos começar a entender a estrutura da aplicação criada.

Estrutura básica de uma aplicação MVC

estrutura básica solution

Seguindo a imagem acima temos bastante conteúdo pra começar. Inicialmente temos a pasta App_Data, que quando necessária é utilizada como repositório de dados e também contâiner de arquivos XML, temos também os arquivos de configuração, o já conhecido Web.config, responsável pelas configurações da página Web como um todo, como chaves de conexão a banco de dados, formas de autenticação, versão do .NET Framework utilizado, etc.

Temos também o Global.asax, já conhecido por muitos que trabalham ou trabalharam com Web Forms, onde no framework anterior servia para que você escrevesse código que rodava em resposta a eventos a “nível do sistema”, como o início e erro da aplicação, o final de uma sessão, etc, ele sempre foi de certa forma opcional no Web Forms e muitos não usavam, dependendo do escopo do projeto. No MVC ele tem uma importância até maior pois funciona como o coração da aplicação, definindo métodos iniciais para o bom funcionamento do sistema como um todo, em muitos casos.

Os métodos que são criados inicialmente são os seguintes.

1

Eles representam os registros iniciais dos conteúdos utilizados na criação da aplicação.

  • O método RegisterAllAreas é responsável por registrar todas as áreas da aplicação. Áreas são módulos funcionais independentes da aplicação que imitam as estruturas de pastas e convenções do MVC. Mais sobre áreas neste artigo e também neste;
  • O método RegisterGlobalFilters são utilizadas na aplicação como um filtro para requests inválidos e outros processamentos pertinentes a aplicação em si. Mais sobre estes filtros neste artigo;
  • O método RegisterRouters é utilizado para registrar as rotas utilizadas pela aplicação, mais sobre rotas será comentado em artigo futuro;
  • O método RegisterBundles é o responsável por registrar o caminho de toda a parte de arquivos relacionados do lado cliente, como Javascript, CSS, HTML, etc, fazendo com que a aplicação “saiba” que estes arquivos devem ser utilizados por ela. Recomendo a leitura deste artigo em português, que explica em detalhes o uso de Bundles e Minifiers.

Sobre os três últimos pontos citados existem três classes respectivas que estão localizadas dentro da pasta App_Start e são necessários para o correto funcionamento da aplicação, baseados nestes pontos.

app_start

Recomendo abrir cada classe para entender o funcionamento delas, explicado nos pontos anteriores sobre Global.asax.

Dentro da pasta Content temos os arquivos css, é nela que também é são incluídos imagens e dependendo do projeto arquivos html representando todo o layout das páginas. Como o conteúdo é imenso pensando no layout temos separado também as pastas fonts e Scripts, cada um com respectivamente as fontes e scripts necessários para a construção do layout, todos baseados no conceito de Bootstrap, que é um framework responsivo para CSS, HTML e JS.

E por último mas não menos importante temos as três principais pastas que compõem toda a estrutura básica de uma aplicação MVC, que são Models, Views e Controllers. Basicamente a pasta Models está vazia, na pasta Controllers temos a HomeController e na pasta Views temos a maior parte do conteúdo.

Importante: toda classe criada na pasta Controllers deve terminar seu nome com Controller, e dentro da pasta View cada subpasta com exceção da Shared, identifica para qual controller a view aponta, logo os nome das subpastas e das controllers devem ser iguais, como boas práticas e para evitar confusões futuras. No exemplo do projeto criado temos três páginas na subpasta Home que vinculam seu conteúdo para a HomeController.

Para entender melhor o funcionamento de uma aplicação MVC precisamos inicialmente analisar o conteúdo da pasta Views.

views

Temos criadas três páginas dentro da pasta Views > Home, sendo que as três são controladas pela classe HomeController, explicado anteriormente, com o sufixo cshtml, que nada mais é que a extensão do Razor, que é a chamada view-engine do ASP.NET MVC. Não confundir Razor com uma nova linguagem de programação, ela é uma espécie de auxílio na codificação das páginas em MVC, permitindo o uso em conjunto de marcações html com código, seja C# ou VB.NET (que neste último caso teriam a extensão vbhtml).

De início achei meio estranho, e lembrei um pouco do ASP clássico (ASP3), mas com o tempo você irá se acostumar a utilizar o Razor em seus projetos, acredite.

Se você olhar a classe HomeController irá notar que na mesma classe temos métodos para as três páginas criadas na View, e todas elas tem como retorno um objeto do tipo ActionResult.

É importante sabermos o conceito de um método action. Basicamente todos os métodos de uma classe do tipo Controller são chamadas de action methods, ou métodos action. São iguais em sua criação a quaisquer outros métodos mas tem algumas restrições:

  • Um método action deve ser público, ou seja, não pode ser privado ou protegido;
  • Um método action não pode ser sobrescrito;
  • Um método action não pode ser estático.

Com isso em mente, seguindo a explicação do blog ExceptionNotFound (ótimo nome para um blog de programação, a propósito), ActionResult é uma classe abstrata que representa o resultado de um método action. Esta classe tem um método também abstrato (sem implementação) chamado ExecuteResult que por sua vez terá sua implementação feita por classes derivadas que herdam o ActionResult.

ActionResult é uma classe abstrata porque assim diferentes actions (métodos) podem retornar diferentes tipos de dados e ainda assim ter o suporte do MVC para manipulá-los corretamente. Veja os exemplos do blog citado acima e confira que diversos tipos de resultados podem ser retornados em um ActionResult, inclusive JSON.

homecontroller

Olhando para a classe Controller no início pra mim ficou um pouco “estranho” o conceito de que eu consigo controlar e programar três páginas em uma mesma classe, neste caso as páginas Index, About e Contact, da subpasta Home, da pasta Views. Mas esse é um ponto forte do MVC, chega de ficar criando aquele monte de página .aspx e codificar em cada página as vezes códigos parecidos ou iguais para fazer a mesma coisa. Acredito que ganhamos muita flexibilidade com esse conceito.

Assim ao rodar o projeto você irá notar que é muito fácil alterar tanto o código de cada página por estes métodos quanto alterar a view trabalhando com a engine Razor em cada página específica.


É isso, abordei alguns pontos básicos e importantes de uma aplicação em ASP.NET MVC. Sugiro muito o estudo e pesquisa nos links postados e procura própria por mais exemplos.

No próximo artigo irei falar do Routing e de outros conceitos importantes de uma aplicação MVC que ficaram de fora deste artigo.

Abraço.

Expresse sua opinião!

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s