O documento fornece uma introdução ao framework ASP.NET MVC, descrevendo suas principais características e componentes, como Models, Views e Controllers. O autor também discute abordagens de desenvolvimento como Code First e Database First e ferramentas como Razor e HTML Helpers.

1. Treinamento ASP.NET
MVC 4.0
POR MICHAEL COSTA

2. Introdução
Treinamento de nível básico, indicado para quem não
conhece, ou teve pouco contato com a tecnologia
Pensado tanto para quem iniciará o desenvolvimento no
framework quanto quem apenas irá atuar como solicitante
da fábrica.
A versão de referencia do framework .net é a 4.5, com MVC
4.0 e Visual Studio 2012 ou superior.
2

3. Um pouco de história
De onde vieram, o que comem, para onde vão e quanto ganham as diversas
linguagens e frameworks que fazem parte da nossa vida...

4. Web Pages
Mistura-se código HTML com
dinâmico.
Controles dinâmicos baseados em
processamento realizado no servidor.
Aprendizado Simples.
Indicado para construção de
pequenos sites.
Desvantagem: Pouca reutilização,
lógica mal estruturada.
4

5. Web Forms
Similar ao modelo Desktop (controles
e eventos)
Fluxo de fácil aprendizagem
Lógica dos comandos e eventos
separada da parte visual.
Bom para aplicações intranet.
Desvantagem: Fácil acabar
misturando as responsabilidades nas
camadas de negócio.
Difícil de adotar
metodologias de teste.
5

6. Esqueça tudo sobre desenvolvimento web!
Pois agora eu lhes apresento...

7. ASP.NET MVC
Separação lógica entre as
responsabilidades de negócio
Estrutura padronizada
Facilita desenvolvimento orientado a
testes (TDD)
Tratamento elegante de rotas e links
Indicado para aplicações “sérias”
Já é uma tendência mundial
Desvantagem: Apesar dos
aceleradores, a curva de aprendizado
é maior
7

8. O fato é que...
... a fila andou.

9. Voltando ao que interessa
(espero que tenha gostado da viagem no tempo)
O que significa essa sopa de letrinhas?
- Model Representa em classes os objetos gerenciáveis pela sua aplicação. Ex.: Carro.
- View Responsável pela apresentação dos dados representados pelo
model. Ex.: Lista de Carros.
- Controller Faz o meio-campo entre a tela e o sistema.
Recebe requisições, selecionam a view responsável
pelas ações recebidas, instancia classes necessárias
para preenchimento dos models e devolve
para o usuário a representação destes
através das Views.
9

10. Templates do ASP.NET MVC
Basicamente 8 templates no framework 4.0:
Empty
Basic
Internet Application
Intranet Application
Mobile Application
Web API
Single Page App
Facebook Application
Updates do VS, incluem novos templates, totalmente
compatíveis com VS sem update!
10

11. Estrutura do projeto
Para Intranet Application, por ex., temos a seguinte extrutura:
App Data: Arquivos de banco de dados, XML, etc. Somente a
própria aplicação tem acesso à este diretório durante o
runtime.
App Start: Classes que executam códigos na inicialização do
programa, é uma separação mais estruturada do Global.asax
Content: Arquivos CSS, imagens relacionadas aos temas bem
como arquivos que precisam ser publicados junto à aplicação.
Controllers: Classes controladoras. Pelo template, já vem um
controlador de autenticação e um para a página Home.
Filters: Classes para pré-processamento dos Controller
Actions.
11

12. Estrutura do projeto
Images: Imagens utilizadas no projeto. CSS’s da pasta
Content podem referenciar imagens daqui.
Models: Classes de negócio do projeto. Em projetos
grandes, é possível separar estas classes em um
projeto separado, mas mantendo esta estrutura.
Scripts: Arquivos JavaScript, incluindo classes de
bibliotecas como jQuery por exemplo.
Views: Templates para renderização de interfaces.
Para cada controller é usual termos uma pasta com o
mesmo nome aqui dentro. Na subpasta Shared,
ficam views reaproveitáveis, semelhante ao master-
page do web forms).
12

13. Abordagens de Desenvolvimento

14. Database
First
Aplica-se aos cenários onde já
existe um banco de dados
criado, ou quando preferimos
modelar e criar o banco de
dados todo antes do sistema.
Neste caso, o Entity Framework
(EF) analisa o banco e gera os
mapeamentos em arquivos
.edmx, chamados Model Files.
14

15. Model
First
Criamos os Model Files
(.edmx) através da
ferramenta de modelagem
do Visual Studio e durante a
execução do código o EF se
incumbe de criar as tabelas
e colunas representadas
pelos models.
15

16. Code First
Neste modelo, nós mesmos
escrevemos os models e o
EF criará o banco de dados
assim como no modelo
anterior.
O desenho do projeto
começa nos models.
16

17. Aprofundando

18. Características do Model
 São as classes que usamos para representar os dados que
iremos trabalhar. Eles carregam tudo entre o banco de dados e a
interface, e devolvem para o banco persistir as alterações
realizadas pelo programa.
 Implementamos na forma de POCOs (Plain Old CLR Object), ou
seja, estruturas simples de dados do modelo de domínio que
representam o negócio.
 Podem ser o ponto de partida no desenho da aplicação.
Iniciando no modelo de domínio, todas as demais partes do
sistema são criadas baseando-se nestes.
18

19. Recursos do Model
Podemos descrever comportamentos do objeto, por ex.:
A forma que ele será descrito na tela
Se o atributo é obrigatório
Se há um tipo específico de dados a ser validado, e
inclusive informar expressões regulares (RegEx) para a
validação.
Mensagens de alerta em caso de erro na validação do
atributo.
19

20. Recursos do Model
Definimos relacionamento entre as classes, como
exibir os dados e como validar. Com isso, garantimos
o reuso. Independente do utilizador, o
comportamento segue transparente.
Responsáveis por descrever as informações e
objetos manipulados pela aplicação, são o coração
da aplicação web.
20

21. Mão na Massa
Vamos criar um model

22. Model Binders
Acostumados com WebForms sabem que leituras de
dados enviados do formulário são acessadas via
Request. No MVC, existe um mecanismo mais
inteligente, chamado Model Binder.
Ele cria a instancia de uma classe model, baseado
nos dados enviados pelo objeto Request. Analisa
tanto os parâmetros esperados pela Action do
Controller, quanto os parâmetros enviados pela tela.
22

23. Model Binders
Ele nos livra de ter de escrever “boilerplate code”, ou
seja, todos os mapeamentos de
Response.QueryString/Forms, e também conversões
de tipo, o que além de consumir bastante tempo, nos
expõe a erros, validação de nulos, dentre outros.
23

24. Model Binders
O componente Model Binder pode ser customizado,
para atender a necessidades além do padrão
oferecido pelo framework.
Um exemplo, seria construir um model binder
customizado que leia do LocalStorage do browser, ao
invés de apenas ler os objetos do Request.
24

25. Controllers
Ponto central. É onde instanciamos models,
executamos operações, persistimos dados, e
retornamos a view correspondente a solicitação.
Basicamente classes compostas por Actions.
Por padrão, as Actions retornam um objeto do tipo
ActionResult. Mas alternativamente, pode-se
retornar uma classe que derive desta.
25

26. Controllers
O fluxo de requisição/retorno dos Controllers,
funcionam respeitando o protocolo HTTP, ou seja,
trabalha com verbos.
Verbos HTTP nada mais são que um conjunto de
operações sobre recursos.
Os principais utilizados são GET/POST/PUT/DELETE.
26

27. Controllers
Um verbo diz ao handler do MVC, qual Action ele
deseja chamar, isto porque duas actions podem ter o
mesmo nome, mas com comportamentos diferentes.
Uma mesma action pode ter comportamentos
diferentes ao ser solicitada,
e ao ser respondida.
27

28. Controllers
Pela utilização de HttpGet, HttpPost, dentre outros,
habilitamos o MVC a identificar qual o cenário em
execução.
Quem nunca teve de utilizar um parâmetro
informando a operação, ou ter de
separar a funcionalidade em dois programas?
28

29. Mão na Massa
Vamos criar um controller

30. Views
Views são o terceiro pilar. Numa mistura de código
HTML e código server side, são responsáveis pela
exibição do resultado das requisições.
Requerem conhecimento
de HTML e Razor
30

31. Views
No WebForms, componentes dinâmicos eram gerados
automaticamente. Perdia-se o controle do HTML e certas
customizações requeriam mágica.
No MVC, temos total liberdade de customização.
Templates podem ser totalmente criado por Web
Designers.
A manipulação do DOM é muito mais simples, pois há
previsibilidade no documento processado.
31

32. Views
32
Podemos dizer então que, uma view apresenta os dados de
um model retornado por um controller.
Ou seja, se você precisar exibir o modelo de um Carro,
basta criar no HTML uma área para tal, e associar ao
atributo correspondente do model.
Apesar de editar código HTML, ao informarmos qual o
model a utilizar, o Visual Studio fornece tipagem forte e
IntelliSense, facilitando o desenvolvimento e validando
erros durante a escrita da classe.

33. Views
O resultado de uma view, é a mesclagem de
marcações HTML com os HTML Helpers, que cuidam
de processar conteúdo dinâmico.
Existe ainda o conceito de Partial View, onde várias
views podem compor uma necessidade mais
complexa. Por exemplo, um painel informando quem
alterou um registro por último.
33

34. Exibição e Validação de Dados

35. Data Annotations
Podemos enriquecer um model através do recurso
Data Annotations, onde habilitamos o MVC a criar
lógica de exibição e validação de dados
É muito simples, basta decorarmos cada
propriedade do model com as
combinações que atentam ao objetivo.
35

36. •Indica que o atributo é obrigatório
Required
•Indica a quantidade de caracteres permitidos
StringLength
•Indica o tipo do atributo, usado na hora de montar o controle HTML5
DataType
•Indica qual o rótulo a ser exibido para o atributo
DisplayName
•Indica qual o padrão de formatação do atributo
DisplayFormat
•Indica qual a extensão de valores permitidos para o atributo
Range
36

37. using System;
using System.ComponentModel;
using System.ComponentModel.DataAnnotations;
namespace LivroMVC.Models
{
public class Car
{
public int CarID { get; set; }
[Required]
[StringLength(120)]
public string Modelo { get; set; }
[DisplayName("Ano/Fabricação")]
public short AnoFabricacao { get; set; }
[DisplayName("Ano/Modelo")]
public short AnoModelo { get; set; }
[DataType(DataType.DateTime)]
[DisplayName("Data de Aquisição")]
[DisplayFormat(DataFormatString = "{0:dd/MM/yy}")]
public DateTime DataAquisicao { get; set; }
[StringLength(8)]
public string Placa { get; set; }
}
}
37

38. Front end

39. Razor
É uma uma linguagem de renderização utilizada nas
views para interpretação de código server side, ou seja,
tudo que estiver escrito em Razor será executado no
servidor antes deste devolver o código HTML já
processado.
É uma alternativa ao ASPX, que era o padrão até a
versão 2 do MVC, e possui vantagens
que o faz diferenciado
39

40. Razor
 Seu aprendizado é muito fácil, qualquer experiência com
HTML e linguagens derivadas de C (como C#), é suficiente
para começar.
 Para quem utiliza testes unitários, é possível pré-compilar
as views em tempo de design e testar o resultado esperado.
 Código mais limpo, por se tratar de uma linguagem menos
verbosa.
 Suporte ao IntelliSense no Visual Studio.
40

41. Utilização do Razor
 Arquivos Razor são criados na extensão .cshtml e
são processados pelo motor do ASP.NET.
Durante o processamento da view, é identificado o
código server side através do símbolo @. Qualquer
código sem este símbolo não é interpretado pelo
Razor e é entregue no arquivo final como um HTML
puro.
41

42. • Comando server side, e logo em seguida será
escrito o código Razor@
• Texto plano, para impresso de uma linha de texto
livre.
• Para mais de uma linha, utilize a tag <text></text>@:
• Criação de comentário, sempre termina com *@
@*
• Inicio de bloco de código, sempre termina com }
@{
42

43. • Criação de condicional@if
• Criação de laço para iteração em coleções@foreach
• Deixa a view fortemente tipada a um model.
• Habilitar IntelliSense
• Previne erros de digitação
@model
43

44. HTML Helpers
No modelo WebForms, trabalhavamos com diversos
componentes visuais, e o engine os renderizava,
criando as tags HTML. Uma abordagem prática mas
que limita muito a manipulação do DOM.
Já no MVC, temos liberdade para escrever o HTML,
mas sem necessidade de escrever Boilerplate Code,
afinal o MVC nos oferece diversos helpers para
criação de elementos.
44

45. Html.ActionLink()
Este helper cria conforme os parâmetros informados
um elemento do tipo <a>. A sua assinatura padrão
espera pelo texto a ser exibido e o nome da action a
ser executada no controller. Veja um exemplo de
utilização e logo abaixo o resultado do HTML
renderizado
@Html.ActionLink("Create New", "Create")
<a href="/Car/Create">Create New</a>
45

46. Html.Action()
Suponhamos que você precisa gerar o action, mas irá
usá-lo em uma image e não e um <a>. Neste caso
pode-se utilizar o helper Html.Action(), veja abaixo
<img src="@Html.Action("Get", new {id = GOD6565})"/>
<img src="/Carro/Get/GOD6565"/>
46

47. Html.DisplayNameFor()
Este helper é utilizado para exibir o nome de uma
propriedade em um model. Sempre é levado em
consideração o que foi definido nos Data Annotations
para obter a descrição a ser renderizada. Ex:
<th>@Html.DisplayNameFor(model => model.AnoFabricacao)</th>
<th>Ano/Fabrica&#231;&#227;o</th>
47

48. Html.DisplayFor()
Este helper é utilizado para exibir o conteúdo de
uma propriedade em um model. É também levado
em consideração o que foi definido nos Data
Annotations para identificar o componente a ser
renderizado que melhor acomode os dados na tela.
<td>@Html.DisplayFor(model => model.Modelo)</td>
<td>@VW Golf Highline 1.4 TSI</td>
48

49. Html.BeginForm()
Este helper é utilizado para criação de formulários,
renderizando o elemento <form> para comportar os
demais controles aninhados a esse. Utilizamos o
comando using, para garantir que não deixe de ser
fechado a tag </form>.
@using (Html.BeginForm()) {…}
<form action="/Car/Edit/1" method="post">…</form>
49

50. Html.LabelFor()
Este helper é análogo ao DisplayNameFor, contudo,
ele renderiza o texto em um elemento <label>,
enquanto o primeiro apenas escreve o conteúdo da
propriedade.
@Html.LabelFor(model => model.Modelo)
<label for="Modelo">Modelo</label>
50

51. Html.EditorFor()
Renderiza um elemento para edição de conteúdo
É criado um elemento do tipo mais apropriado para
exibir o dado, sempre levando em consideração o
Data Annotation.
@Html.LabelFor(model => model.Descricao)
<textarea class="text-box multi-line" id="Descricao"
name="Descricao">Disponibilidade do modelo sob consulta</textarea><span
class="field-validation-valid" data-valmsg-for="Descricao" data-valmsg-
replace="true"></span>
51

52. Html.ValidationSummary()
Este helper é utilizado para renderizar o sumário de
erros encontrados na validação do form, sua
utilização dar-se-á da seguinte forma:
@Html.ValidationSummary()
52

53. Html.ValidationMessageFor()
Exibição de mensagem de validação individual para cada
propriedade na view.
@Html.EditorFor(model => model.Classificacao)
@Html.ValidationMessageFor(model => model.Classificacao)
<input class="text-box single-line" data-val="true" data-val-number="The field
Classificação must be a number." data-val-range="The field Classificação must be
between 0 and 5." data-val-range-max="5" data-val-range-min="0" data-val-
required="The Classificação field is required." id="Classificacao"
name="Classificacao" type="number" value="5" />
<span class="field-validation-valid" data-valmsg-for="Classificacao" data-valmsg-
replace="true"></span>
[DisplayName("Classificação")]
[Range(0, 5)]
public int Classificacao { get; set; }
53

54. Html.ValidationSummary()
Este helper é utilizado para renderizar o sumário de
erros encontrados na validação do form, sua
utilização dar-se-á da seguinte forma:
@Html.ValidationSummary()
54

55. Rotas

56. Rotas
Uma rota nada mais é que uma forma mais elegante de
estruturar as chamadas das páginas. No Asp.Net geralmente
chamamos páginas de uma forma parecida com a seguinte:
http://servidor/site/funcionalidade/tipo/aplicacao.aspx?param1=a&param2=b
Costumamos organizar nossas aplicações em subdiretórios
que às vezes podem criar N sub-níveis gerando links
extensos e confusos, e no fonte precisamos tratar N
parâmetros manualmente.
56

57. Rotas
No MVC, existe o conceito de rotas. Através da rota o
Asp.Net sabe exatamente qual programa executar,
qual a ação desejada e quais parâmetros consumir e
de uma forma quase automática. Veja o exemplo de
uma rota padrão:
http://servidor/controller/action/param
57

58. Rotas
Consideremos a seguinte rota:
http://seminovos.localiza.com/carro/exibir/GOD6565
Sendo Carro o controller, Exibir a action e GOD6565
o parâmetro, teremos no projeto um arquivo
Controllers/CarroController.cs, contendo uma action
com o nome Exibir, e que espera um parâmetro
chamado Placa, que no caso é a chave da tabela
Carro.
58

59. Rotas
Por convenção do MVC, models sempre ficam na
pasta ~/Models, controllers sempre ficam na pasta
~/Controllers e as views sempre ficam na pasta
~/Views.
Esta é a rota padrão no Asp.Net, mas é possível
customizar as rotas conforme desejado, através do
arquivo ~App_StartRouteConfig.cs.
59

60. Exemplo de Customização de Rota
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
name: "DefaultCar",
url: "{controller}/{action}/{id}",
defaults: new { controller = "Car", action = "Index", id =
UrlParameter.Optional }
);
routes.MapRoute(
name: "Default",
url: "{controller}/{action}/{id}",
defaults: new { controller = "Home", action = "Index", id =
UrlParameter.Optional }
);
}
60

61. Rotas
Para fins de usabilidade, e melhorar o ranking dos
mecanismos de busca (SEO), é possível fazer as URLS
ficarem ainda mais amigáveis, ex:
http://seminovos.localiza.com/GOD6565
Para isso, criamos uma configuração que quando não
fosse informado controller e action, automaticamente
direcionasse para o controller Carro, action Exibir e
passar como parâmetro GOD6565.
61

62. Atualização parcial (Ajax/jQuery)

63. Atualização parcial (Ajax/jQuery)
Um dos conceitos de desenvolvimento de aplicações Web
modernas, é a realização de atualizações parciais de página.
Na web tradicional, toda atualização de informações
requeria que a página inteira fosse postada e recarregada,
tomando assim bastante tempo de navegação.
Neste modelo, o usuário recebe a página inteira na
primeira vez, e a medida que precisa de novas informações,
ou atualização de algum dado em específico, requisita ao
servidor e atualiza apenas aquele bloco.
63

64. Atualização parcial (Ajax/jQuery)
Para implementar páginas com atualização parcial,
pode-se criá-las normalmente, sem AJAX, e depois
adicionar e/ou modificar as views e controllers para
atualizar somente pedaços específicos.
Com uma aplicação pronta, testada e livre de erros,
criamos uma view, chamada de partial view, inclindo
apenas o trecho da página que receberá atualizações.
64

65. Atualização parcial (Ajax/jQuery)
O ASP.NET MVC nos fornece um helper chamado
Ajax.ActionLink, no qual informamos qual ação será
chamada do Controller e onde deverá ser atualizado.
Vejamos um exemplo:
<div id="divAtualizacao">@ViewBag.Message</div>
@Ajax.ActionLink("Atualizar","MensagemAtualizacao", new AjaxOptions{ HttpMethod =
"POST", UpdateTargetId = " divAtualizacao ", InsertionMode =
InsertionMode.Replace })
65

66. Atualização parcial (Ajax/jQuery)
Este bloco, buscará no servidor um método, que quando
chamado via HttpPost, com o nome MensagemAtualizacao,
substituirá o conteúdo da seção divAtualizacao.
public class MeuController : Controller
{
[HttpPost]
public PartialViewResult MensagemAtualizacao()
{
ViewBag.Message = “Atualizado em” + DateTime.Now.ToString();
return PartialView();
}
}
66

68. Sugestões de pesquisa
Utilização e customização de CSS
Responsividade (Versão Mobile x Desktop)
jQuery
Unit Testing (TDD)
Caching
WebAPI
Azure
68