ASP.NET MVC: Desenvolvendo uma aplicação na prática

Por que eu devo ler este artigo:Nos dias de hoje, aplicações web são utilizadas para as mais variadas coisas, e é muito importante que exista uma tecnologia avançada para desenvolvê-las. O ASP.NET MVC é e essa tecnologia, pois possui uma separação de conceitos muito clara, auxiliada pelo padrão MVC, além de uma segurança que, quando bem feita, garante que o site estará tão seguro quanto possível.

Nessa primeira parte de nossa série que pretende criar um controle financeiro, utilizando os principais recursos da plataforma e explicando cada um deles, iremos trazer uma introdução ao ASP.NET MVC e como utilizar o Razor para criar um layout interessante para nossa aplicação.

O desenvolvimento de web sites, ou aplicações web, evoluiu muito nos últimos anos. Isso fez com que muitas empresas começassem a procurar a construção de suas aplicações na web, e não mais utilizando tecnologias que as deixavam presas a um desktop, como Windows Forms ou WPF.

Com isso, o ASP.NET MVC tornou-se uma grande arma dos desenvolvedores e empresas de desenvolvimento para a criação de aplicações web seguras e confiáveis. Isso acontece porque o modelo de programação do ASP.NET MVC foi criado com o específico intuito de criar as melhores aplicações web da nova geração.

Ao longo dessa série, iremos apresentar o ASP.NET MVC e seus principais conceitos, técnicas e ferramentas. A ideia é que o leitor, ao final dela, possa entender e aplicar esse conhecimento para a criação de grandes aplicações web utilizando essa tecnologia. O objetivo não é a criação de um tutorial, e sim de algo que possui grande quantidade de teoria para que seja possível o entendimento do que está sendo feito ao invés de uma simples reprodução.

Na primeira parte dessa série, iremos trazer uma introdução ao ASP.NET MVC. O que é, porque foi criado e como, entre outros assuntos. Um dos grandes focos será no padrão MVC, que é a base dessa tecnologia. Isso significa que iremos entender como interagem os Controllers, Models e Views em uma aplicação ASP.NET MVC, além de começarmos a criação do projeto que será concluído em etapas ao longo de nossa série. Conforme a série vai avançando, a intenção é ir se aprofundando nos conhecimentos, utilizando ferramentas e técnicas mais avançadas para a criação de nossas aplicações web com ASP.NET MVC.

Além disso, estaremos apresentando dois conceitos essenciais em aplicações em geral: o visual da mesma e sua capacidade de lidar com dados. Vamos entender como funciona o Razor, grande aliado no desenvolvimento das views de nossa aplicação. O Razor é o chamado view engine (BOX 1), e é responsável por processar conteúdo ASP.NET e instruções.

Da parte de dados, iremos entender como lidar com injeções de dependência utilizando o Ninject, além de prepararmos o terreno para a criação da base de dados de nossa aplicação. Para isso, iremos criar um repositório de dados abstrato, além de um repositório simulado, que será utilizado para testes.

BOX 1: View Engines no MVC Framework

O ASP.NET MVC possui vários tipos de motores de vistas (ou view engines). Algumas versões atrás, o padrão era o conhecido ASPX, que acabou perdendo espaço para o Razor (CSHTML) em versões mais recentes. Os view engines são responsáveis pela renderização de todo o HTML das views no navegador. Em outras palavras, eles controlam tudo que diz respeito à página e os controles que serão mostrados na mesma. Além do Razor e do ASPX (que ainda pode ser utilizado), a Microsoft permite a utilização de iniciativas de terceiros, entre as quais merecem destaque o Spark e o NHaml.

O Padrão MVC

Primeiramente, precisamos entender que o padrão MVC não foi criado para o ASP.NET especificamente. Trata-se de um padrão de projetos que vem evoluindo desde os anos 1970, quando surgiu em um projeto da Xerox, como um meio de organização das GUI (Graphical User Interface – Interface Gráfica do Usuário) da aplicação. Sem dúvida nenhuma, o padrão evoluiu muito nesses anos e, embora o conceito inicial permaneça, o MVC presente no ASP.NET MVC é muito diferente da primeira versão dos anos 1970.

Quanto ao padrão MVC em si, ele significa, em poucas palavras, que a aplicação irá ser dividida em três camadas básicas: Models, Views e Controllers. Os modelos (Models) contém ou representam os dados que o usuário irá utilizar na aplicação. Já as vistas (Views) são utilizadas para mostrar alguma parte do modelo como uma interface de usuário, de alguma forma que faça sentido para qualquer usuário sentado à frente da aplicação. Por fim, os controladores (Controllers), como o nome sugere, controlam a aplicação, processando requisições do usuário, realizando operações nos modelos e selecionando as vistas para serem mostradas ao usuário. Todos esses conceitos serão explorados mais a fundo nas próximas seções.

O conceito de separação de camadas não é uma ideia exclusiva do padrão MVC e, no mercado, há outros padrões de arquitetura de software (BOX 2) que trazem conceitos similares.

É interessante que demos uma olhada nessas alternativas porque podemos aprender muito sobre o MVC com seus companheiros de causa. Isso significa que o MVC não é o padrão perfeito para todas as situações; nada é. No caso de aplicações web, porém, seja com ASP.NET ou com outras tecnologias, o MVC é uma tecnologia muito interessante de ser usada e, como já está preparada para esse meio, traz diversas vantagens que não são vistas nos demais padrões.

BOX 2: Padrões de arquitetura de software

Hoje em dia, com o aumento geral do tamanho dos softwares desenvolvidos, é muito importante que tenhamos padrões, ou o entendimento seria inviável. O primeiro desses padrões, além do MVC, claro, é o Smart UI, ou interface de usuário inteligente, utilizado no Windows Forms e no ASP.NET Web Forms. Esse padrão se comunica com o usuário através de eventos, que funcionam como requisições e respostas. Ao mesmo tempo, a aplicação se comunica com os dados, normalmente em uma base de dados relacional. Isso significa que não há uma separação de conceitos, tornando a manutenção desse software muito custosa. A Figura a ilustra esse padrão.

Os demais padrões nada mais são que variações do próprio MVC, baseados na mesma arquitetura chamada de model-view. Nos casos desses padrões, temos um modelo em três camadas, o modelo, a vista, e um terceiro elemento responsável pela ligação entre os dois, normalmente para proteger o modelo de acesso direto.

Existem vários desses padrões, onde os mais comuns são o MVP (Model-View-Presenter), onde o apresentador (Presenter) possui as mesmas responsabilidades do Controller no MVC, com a diferença de que ele trabalha mais diretamente na vista, manuseando diretamente valores mostrados na UI; e o MVVM (Model-View-ViewModel), onde a View Model é uma representação abstrata da vista, lidando com propriedades dos dados e operações nesses dados que podem ser invocadas das vistas da aplicação.

Quando trabalhamos com MVC, um dos objetivos que devemos ter é a criação de elementos que permitam a separação muito clara de conceitos.

Isso irá trazer diversos benefícios para a aplicação em geral, tanto em termos de desempenho, confiabilidade, segurança e manutenção, como em outros pontos. Afinal, é muito mais simples de controlarmos uma aplicação em que conhecemos a função de cada coisa, e cada um dos elementos está destinado a trabalhar em uma área apenas. Além disso, o mínimo possível de interdependências é muito importante. Isso significa que a aplicação precisa ser loosely coupled, ou em uma tradução literal, casada muito fracamente.

Para criamos uma aplicação que siga esse conceito, não é muito simples. Em termos de programação, isso significa que cada componente da aplicação não saiba nada dos outros componentes concretos e apenas lide com outras áreas da aplicação através de interfaces abstratas. Por exemplo, se eu tenho uma classe concreta EnviarMensagem, é preciso que ela implemente uma interface IEnviarMensagem (nome padrão). Assim, todas as classes que quiserem enviar mensagem irão utilizar a interface, ao invés de utilizar a classe diretamente. Isso é mostrado na Figura 1.

Entretanto, mesmo com a utilização de interface, ainda há o problema da dependência entre as classes. Isso porque, mesmo que criemos um objeto do tipo IEnviarMensagem, vamos precisar da palavra chave “new” para criar um novo objeto do tipo EnviarMensagem, como mostrado a seguir:

Para evitarmos esse uso, a utilização da chamada Dependency Injection, ou injeção de dependência, é necessária. Essa técnica, que veremos em mais detalhes ao longo da série, remove todas as dependências de classes concretas do nosso componente e então injeta (daí o nome) containers de dependências que serão resolvidos em tempo de execução. Esse tipo de implementação também auxiliar nos testes, pois é possível a implementação de uma classe fake (Mocked Implementation), muito comum em testes.

Agora que conhecemos o MVC e sabemos do que ele é capaz, vamos entender o que é o ASP.NET MVC e onde ele se encaixa no mercado de desenvolvimento hoje em dia. É importante ressaltar que o MVC não trabalha sozinho. É preciso que o desenvolvedor planeje seus passos e como irá dividir o software, pois o padrão só é tão bom quanto o desenvolvedor que o utiliza.

ASP.NET MVC em contexto

O ASP.NET MVC veio ao mercado como uma forma de substituir, aos poucos, o ASP.NET Web Forms. Essa mudança de ideia por parte da Microsoft aconteceu devido a alguns problemas no Web Forms, que tinha uma ideia excelente por trás, mas a realidade não se provou tão linda.

Há problemas com controle sobre o HTML, que é muito limitado, o mecanismo de controle dos estados das vistas gera muita transferência de dados, sem contar que não há nenhum tipo de separação de conceitos, ainda que possa haver essa sensação devido ao code-behind. Outro ponto importante é que a capacidade de testar essas aplicações utilizando as técnicas mais modernas é muito baixa.

Obviamente, esses problemas foram notados nas primeiras versões da plataforma, e hoje em dia ela é muito melhor. Alguns deles, entretanto, não puderam ser resolvidos por serem intrínsecos a plataforma, e por isso a ideia do ASP.NET MVC.

Portanto, vamos começar explicando as principais vantagens que o ASP.NET MVC traz na comparação com o Web Forms e outras tecnologias presentes no mercado.

• Padrão arquitetural: o MVC, como vimos, traz uma organização muito grande para a tecnologia. Além da natural separação de conceitos, ele também traz um ciclo muito claro de execução da aplicação, que começa com a ação do usuário e culmina com as mudanças no modelo de dados e na alteração da view para o usuário.
• Extensibilidade: o MVC Framework da Microsoft, utilizado com o ASP.NET MVC, foi construído como uma série de componentes que podem ser estendidos ou mesmo substituídos em caso de necessidade
• Controle sobre o HTML e o HTTP: o ASP.NET MVC trabalha muito bem com o HTML, através de helper methods (BOX 3) que produzem marcadores claros seguindo um padrão setado por um CSS.

É válido ressaltar que o grande concorrente do ASP.NET MVC não é o ASP.NET Web Forms. Eles acabam assumindo fatias diferentes do mercado devido às suas profundas diferenças (o que é um dos motivos da Microsoft não ter descontinuado nenhum deles).

O grande concorrente do ASP.NET MVC atualmente é provavelmente o Ruby on Rails, que surgiu quieto, sem muito alarde, e foi caindo no gosto da comunidade de desenvolvimento.

A grande sacada dessa tecnologia não é o grande avanço que trouxe em termos de uma nova técnica ou tecnologia: apenas pegou as técnicas e tecnologias que existiam e as uniu de uma forma excelente, criando um sistema de desenvolvimento bastante eficiente.

Ferramentas essenciais

Desenvolvedores de ASP.NET MVC, devido a algumas razões que foram apresentadas, precisam ter outras ferramentas em seu “cinto de utilidades”. Isso porque ele não basta, normalmente, sozinho. Por isso, é extremamente importante que tenhamos conhecimento de algumas ferramentas, de três tipos básicos: um container DI (Dependency Injection), um framework de testes unitários e uma ferramenta de criação de classes fake (Mocking Implementation) para testes.

Primeiramente, temos um container DI. Ao longo dessa série, iremos utilizar o Ninject. É uma ferramenta extremamente simples, elegante e fácil de usar. Embora haja alternativas mais poderosas, o fato de que o Ninject funciona com pouca ou nenhuma configuração é uma das grandes vantagens dessa ferramenta. Uma alternativa a ele é o Unity, da própria Microsoft, o que pode facilitar a utilização com o Visual Studio.

O Ninject irá realizar aquilo que discutimos anteriormente: criar implementações dos objetos e injetá-las no construtor. Ele irá simplesmente eliminar todo tipo de ligação forte entre as classes, criando um sistema loosely coupled.

Para isso, a utilização de interfaces é essencial, assim como é essencial aprender a utilizar o Ninject. Primeiramente, para instalá-lo, basta abrir o Package Manager Console (em Tools-Library Package Manager) no Visual Studio e instalar o pacote, como mostra a Listagem 1. A utilização da linha de comando é mais simples para instalação do Ninject. O primeiro comando instala o Ninject e os demais, extensões para fazê-lo funcionar melhor com aplicações ASP.NET. Os detalhes de funcionamento da ferramenta serão vistos ao longo da série.

 
Install-Package Ninject –version <versão mais recente>
Install-Package Ninject.Web.Common –version <versão mais recente>
Install-Package Ninject.MVC3 –version <versão mais recente>

Quanto a testes unitários, o mais simples é a utilização da ferramenta de testes do próprio Visual Studio. Embora existam outras ferramentas, como o NUnit, a evolução das ferramentas de testes do VS nos últimos anos faz com que seja uma excelente opção, e muito mais fácil de implementar do que outras. O resultado, atualmente, é um sistema de testes unitários totalmente integrado com o IDE, o que sempre é uma coisa que nós, desenvolvedores, desejamos.

Por fim, para criação de mocking implementations, o Moq é uma ferramenta muito interessante. Trata-se de um kit especialmente criado com esse objetivo, e ele traz alguns elementos muito bons para a criação de implementações de interfaces para testes unitários. É interessante aqui que não há meio termo com relação a essa ferramenta: ou você gosta ou não. Outra alternativa é o Rhino Mocks, caso o Moq não seja uma opção interessante para o leitor.

Ao longo do curso iremos entender melhor como utilizar essas ferramentas. Entretanto, o objetivo não é transformar ninguém em um expert nelas, apenas dar um ponto de partida e mostrar como e porque elas podem ser úteis para as suas aplicações ASP.NET MVC. E, obviamente, o leitor é livre para escolher outras ferramentas, se não achar as sugeridas interessantes. Porém, é muito importante que haja um container DI, uma ferramenta para testes unitários e uma para criação de mocking implementations no seu arsenal de utilidades.

Entendendo o Razor

Conforme comentamos acima, o ASP.NET MVC 5 traz o Razor como seu view engine, ou motor de vistas. Essa escolha se dá pelo fato de se tratar de um excelente meio de definir views, seja em termos de layout, separação de lógica e dados, entre outros pontos importantes.

O Razor traz a possibilidade de utilização de elementos de linguagens de programação, como estruturas de fluxo (if) e loops (foreach, por exemplo). Além disso, a utilização das chamadas expressões Razor são uma das grandes vantagens desse engine, permitindo um grande leque de oportunidades ao desenvolvedor.

Em termos de layout, o Razor traz algumas opções interessantes, como, por exemplo, no começo de cada arquivo .cshtml temos um layout definido como nulo e podemos adicionar um layout a cada uma das páginas.

O Visual Studio, nesse caso, nos auxilia bastante. Temos o modelo “MVC 5 Layout Page (Razor)” que podemos criar e vincular a nossa view. O layout funciona permitindo que criemos elementos que serão compartilhados entre as várias páginas. Para identificar os detalhes que são intrínsecos a cada página, podemos utilizar a expressão “@RenderBody()”, que irá indicar qual parte do layout será responsabilidade da própria página. O padrão de nomes dos layouts é que eles sempre começam com “_”, como em “_HomeLayout.cshtml”.

O Razor permite que criemos algo como uma Master Page em nosso projeto através do conceito de arquivo View Start. Esse arquivo traz o layout padrão de todas as páginas, o que essencialmente significa que, caso não haja um layout ligada à página, ela irá utilizar o que está definido. O nome desse arquivo precisa ser “_ViewStart.cshtml”, pois é o nome que o MVC Framework está esperando.

Além disso, é possível criar views fortemente tipadas, com o Razor. Ao definirmos o modelo ao qual a view está vinculada, utilizando a expressão “@model” ou “@Model”, temos acesso a todas às informações que precisarmos do modelo. Nesse caso, o IntelliSense dentro do Visual Studio irá auxiliar o desenvolvedor a escolher as propriedades sem nenhum tipo de erro. No mesmo sentido, temos a “@ViewBag”, que permite que criemos um dicionário de dados entre as views e o controller. Ambos são expressões Razor bastante simples, embora haja muito mais nessas expressões do que essas duas colocações deixem transparecer.

Agora que temos uma noção melhor do que é o Razor, vamos entender as expressões Razor, que é um dos pilares desse view engine. Comentamos e utilizamos algumas delas, inclusive. As expressões Razor são expressões que começam com o caractere “@” e trazem algum detalhe para ser utilizado pela view.

Aqui, precisamos entender que, embora a view seja capaz de alguma programação, devemos deixar essa responsabilidade para o Action Method. Em outras palavras, a view tem a responsabilidade de utilizar o objeto que foi passado pelo Action Method para mostrar conteúdo ao usuário, enquanto o Action Method simplesmente irá passar esse objeto à view.

Dependency Injection (DI) ...

Quer ler esse conteúdo completo? Tenha acesso completo