C#

e ASP.NET MVC
Conceitos principais

Apostila de apoio

STAFF Business
So Jos dos Campos, 2015

Sumrio
1.

Introduo ........................................................................................................................ 3

2.

Conhecendo melhor o C# e o .NET Framework ............................................................... 4

3.

Gerenciamento de memria em uma aplicao .NET, value-types e reference-types .... 7

4.

O padro MVC e o ASP.NET MVC ................................................................................... 15

5.

O protocolo HTTP ........................................................................................................... 19

6.

Persistncia de informaes e a impedncia ................................................................. 23

1. Introduo

Ol, tudo bem?

Seja bem-vindo ao treinamento de ASP.NET MVC da Staff Business. um prazer estar com
voc!
Neste curso, iremos abordar ento o framework para desenvolvimento web da Microsoft:
o ASP.NET MVC. Iremos aplicar o ASP.NET MVC em conjunto com a principal linguagem da
plataforma: o C#. Tambm discutiremos algumas caractersticas da linguagem em si, bem
como tambm abordaremos alguns princpios de arquitetura de software e de Application
Lifecycle Management (ALM).
Este material tem como objetivo servir de apoio e complemento ao contedo prtico do
curso de ASP.NET MVC, detalhando com um pouco mais de profundidade tcnica alguns
conceitos do framework e tambm da prpria linguagem. Neste material voc encontrar
mais referncias tericas e um pouco mais de aprofundamento dos contedos que sero
vistos nas aulas hands on.
Note que, ento, o contedo do treinamento presencial e o contedo desta apostila so
complementares entre si: um contedo no substitui o outro.

2. Conhecendo melhor o C# e o .NET Framework

O C# uma linguagem desenvolvida pela Microsoft. Foi apresentada no ano 2000, junto
com a plataforma .NET, sendo a principal linguagem da plataforma. considerada uma
linguagem multi-paradigma, porm, sua vocao a orientao a objetos. tambm uma
linguagem type-safe (cada varivel de um determinado tipo e somente daquele tipo).
Alguns dos benefcios mais importantes do uso de C# vem seus recursos em tempo de
execuo, que nos oferece servios como segurana sandboxing (execuo de cdigo dentro
de um ambiente controlado), verificao de tipos em tempo de execuo, tratamento de
excees, gerenciamento de thread (cdigos executados simultaneamente) e, talvez o
recurso mais importante, o gerenciamento automtico de memria. Em tempo de execuo
h um coletor de lixo (garbage collector), que livra os desenvolvedores de grande parte do
trabalho associado memria, recuperando o que no mais usado pelo programa. O C#
tambm oferece suporte sem maiores problemas para a utilizao de recursos corriqueiros
de uma linguagem, como conexo bancos de dados e consumo de WebServices.
Atualmente, o C# multi-plataforma e tambm open-source. Toda a gerncia da parte
open source no somente do C#, mas de todos os projetos da plataforma .NET, desenvolvida
pela .NET Foundation, o brao open-source da Microsoft. O C# tambm multi-plataforma
porque hoje existem uma portabilidade do .NET Framework para ambientes Unix (Linux e
Mac) chamada Mono. O Mono tambm um projeto open-source coordenado pela Microsoft
que consiste na portabilidade do .NET Framework do Windows para ambientes Unix. Alm
disso, tambm possvel rodar cdigo native .NET sem o auxlio do Mono graas ao
microframework .NET Core, tambm criado pela Microsoft.
J o .NET Framework uma infraestrutura (framework) sobre a qual se rene um conjunto
de linguagens e servios que simplificam o desenvolvimento de aplicaes. Mediante essa
ferramenta se oferece um ambiente de execuo altamente distribudo, que permite criar
aplicaes robustas e escalveis. Os principais componentes desse ambiente, que sero
detalhados a seguir, so:

Linguagens suportadas pelo .NET;
Biblioteca de classes comuns do .NET Framework;
CLR (Common Language Runtime);
JIT (Just-in-time Compiler)

O .NET Framework suporta mltiplas linguagens de programao e, embora cada
linguagem tenha caractersticas prprias, possvel desenvolver qualquer tipo de aplicao
com qualquer uma das linguagens. Existem mais de 30 linguagens adaptadas a .NET, desde as
mais conhecidas como C#, Visual Basic.NET e C++, at outras linguagens menos conhecidas,
como Perl ou Cobol.
Qualquer uma das linguagens do ambiente .NET duplamente compilada, ou seja:
convertida para uma linguagem intermediria comum entre todas as linguagens do
framework e depois este cdigo comum convertido para cdigo de mquina. Acompanhe o
processo de compilao na ilustrao abaixo:

O processo de compilao e execuo de uma aplicao .NET pode ser detalhado da
seguinte maneira:

Ambiente de desenvolvimento: onde os desenvolvedores escrevem os cdigos
necessrios para o desenvolvimento de uma aplicao. Geralmente, utilizada uma
IDE para auxiliar na escrita do cdigo. Para a plataforma .NET, a IDE mais utilizada o
Visual Studio, da Microsoft;
Compilao: aps a escrita do cdigo, necessrio o converter para uma linguagem
de um nvel mais baixo. No caso especfico do C#, quem faz essa converso, conhecida
como compilao, o executvel csc.exe. No caso de utilizao de IDEs, a prpria IDE
se encarrega de chamar o compilador com os parmetros necessrios, alm de fazer
uma srie de verificaes no cdigo (por exemplo: verificao de erros de sintaxe);
Assembly intermedirio: no caso da plataforma .NET, o cdigo-fonte convertido para
uma linguagem unificada da plataforma .NET, a Microsoft Intermediate Language
(MSIL). Essa converso ocorre devido ao fato de que a plataforma .NET possui vrias
implementaes de diferentes linguagens que, inclusive, podem conversar entre si.
Para isso, necessrio converter todos os cdigos-fonte para uma linguagem nica,
que a MSIL. Atualmente, a MSIL tambm chamada de CIL (Common Intermediate
Language). A CIL/MSIL se assemelha muito ao bytecode da plataforma Java.O MSIL/CIL
ainda apresenta algumas meta- informaes sobre as classes compiladas e seu
contedo nos arquvos gerados pelo processo de compilao e converso para a
MSIL/CIL. importante salientar que o resultado do processo de compilao e
converso para a MSIL ainda no cdigo de mquina (a MSIL/CIL ainda apresenta
at uma certa legibilidade para humanos), e sim uma linguagem unificada
intermediria da plataforma .NET. A converso dos cdigos escritos nas diferentes
linguagens da plataforma .NET para a MSIL/CIL feita de acordo com a Common
Language Specification (CLS), um conjunto de funes bsicas que todas as linguagens
da plataforma devem conter para que seja possvel que uma converse com a outra,
alm de conter o Common Type System (CTS), um conjunto de especificaes para

principalmente efetuar a converso e correspondncia de tipos de dados entre as
diferentes linguagens;
.NET Framework: o conjunto de todos os utilitrios e infraestrutura necessrias para
se executar uma aplicao .NET na mquina-cliente. Os componentes principais do
.NET Framework so:
o Common Language Runtime (CLR): o CLR o verdadeiro ncleo do .NET, j
que o ambiente de execuo onde se carrega e gerencia os cdigos MSIL/CIL;
o JIT (Just-in-Time Compiler): o componente do .NET Framework responsvel
por converter os cdigos MSIL/CIL para o cdigo de mquina correspondente
plataforma onde a aplicao executada. A CLR, quando detecta que
necessrio um trecho de cdigo que ainda no foi convertido para linguagem
de mquina, solicita ao JIT essa converso e, s depois, o cdigo executado,
j no formato de mquina. Esse processo conhecido como Dynamic
Translation (Traduo dinmica);
o o Garbage Collector (GC): componente do .NET Framework que responsvel
por verificar a memria da mquina cliente onde a aplicao executada. Caso
ele encontre uma localizao da memria que contenha alguma informao
que no mais necessria para nenhum processo que esteja rodando dentro
da plataforma .NET (por exemplo: uma referncia para um objeto que no
mais utilizado em nenhum ponto de uma aplicao .NET), o GC limpa a regio
da memria que era utilizada para guardar esta informao e a libera,
permitindo que novas informaes teis sejam gravadas naquela posio de
memria;
o o .NET Class Libraries: um conjunto de bibliotecas prprias do .NET
Framework utilizadas para interao com recursos da infraestrutura do
framework e/ou recursos do sistema operacional. Essas bibliotecas so
utilizadas por qualquer aplicao que seja escrita em cima do .NET Framework.

Ao final do processo de compilao e converso da MSIL/CIL por parte do .NET

Framework, gerado um cdigo de mquina que ser gerenciado pela CLR. Este cdigo de
mquina est otimizado para o ambiente onde a aplicao est sendo executada, o que
adiciona a caracterstica de interoperabilidade ao .NET Framework: basta existir uma
implementao da infraestrutura do .NET Framework para um sistema operacional que j se
torna possvel executar uma aplicao .NET neste sistema, sem necessidade de portabilidade
e/ou reescrita de cdigo para o sistema em questo. Isso tambm possvel graas prpria
MSIL/CIL: no final, todo o cdigo convertido para uma nica linguagem unificada, que no
depende de sistema operacional: ela depende somente da prpria infraestrutura do .NET
Framework.

3. Gerenciamento de memria em uma aplicao .NET, valuetypes e reference-types

O ambiente de execuo do .NET, de maneira geral, divide a memria em duas grandes

reas: a stack (uma rea bem menor) e a heap (uma rea bem maior). A stack, por ser menor
e por contar com um algoritmo de organizao mais eficiente, de acesso muito mais rpido
do que a memria heap.
Podemos ilustrar esta diviso da memria conforme o diagrama abaixo:

As variveis de alguns tipos de dados leves (tipos primitivos - int, double, bool etc. - e
structs) so armazenadas diretamente na stack, a rea menor e mais eficiente para
localizao dos contedos. Elas ficam diretamente nessa rea justamente por serem tipos de
dados que no ocupam tanto espao na memria. O mais interessante que o valor que elas
contm tambm fica junto delas na stack. Ou seja, quando voc faz a declarao abaixo:

int numero = 3;

O compilador armazena essa varivel diretamente na memria stack, como na ilustrao
abaixo:

Perceba que o valor da varivel fica junto com a prpria varivel. Variveis onde isso
acontece so chamadas de Value-Types, justamente porque o valor delas fica junto com a
prpria varivel na memria, alocados na stack. Assim, quando voc tem o seguinte cdigo:

if (numero <= 2)
{
//...
}

O compilador tem acesso direto ao contedo, pois ele est junto com a prpria varivel
na memria:

Agora, outros tipos de dados ocupam muito mais espao de memria do que estes tipos
leves que so value-types. Por isso, eles no podem ser armazenados na stack como os valuetypes. Sendo assim, estes dados so armazenados na memria heap.
Vamos imaginar que voc tenha o seguinte cdigo, com uma classe chamada Pessoa:

class Pessoa
{
public int Id {get; set;}
public string Nome {get; set;}
}

Quando voc cria um objeto dessa classe, esse objeto ser armazenado na memria
heap:

Pessoa minhaPessoa = new Pessoa();

Porm, o compilador no acessa a heap. Por que ele no acessa? Justamente porque ela
muito grande... Se ele fosse procurar o objeto minhaPessoa dentro da heap, ele iria demorar
uma quantidade considervel de tempo. O compilador precisaria ter um jeito de acessar pela
stack (que rpida pra encontrar as coisas) o que est alocado na heap (que bem maior).
Como o compilador contorna isso? Criando uma referncia dentro da stack para o objeto
minhaPessoa, apontando onde na heap que este objeto est de fato guardado.

10

Essa poro de memria que alocada na stack para apontar para uma posio de
memria da heap chamada de ponteiro. Por isso ele tem esse asterisco (*) na frente do seu
nome.
Repare ento que criada uma referncia da stack para uma determinada posio de
memria da heap, referncia essa guardada por um ponteiro na stack. Esse tipo de varivel
(como no caso da varivel minhaPessoa, do tipo Pessoa) chamada de reference-type, j que
necessrio uma referncia da stack para a heap para que esta varivel seja acessvel.
Variveis reference-type geralmente precisam que seja chamado o new, pois ele que define
que uma poro de memria da heap dever ser utilizada para guardar aquele objeto.
Dessa maneira, quando temos o cdigo abaixo:

if (minhaPessoa.Id <= 2)
{
//...
}

O compilador faz o acesso ao objeto minhaPessoa atravs da stack, ou seja, atravs do
ponteiro. Esse ponteiro encaminha o compilador para a posio de memria da heap que
contm de fato o objeto minhaPessoa.

11

Ou seja, resumindo:

Value-Type: so tipos leves que ficam armazenados diretamente na memria stack.

Os valores das variveis ficam armazenados juntamente com as prprias variveis,
sendo o acesso ao seu contedo feito de maneira direta;
Reference-Type: tipos pesados (objetos de classes, etc.) que ficam armazenados na
heap. Para no sacrificar a performance, criada uma referncia (ponteiro) na stack
que aponta para qual posio de memria o objeto est armazenado na heap. O
acesso feito via essa referncia na stack, portanto, o acesso indireto,
dependendo dessa referncia.

Agora, o que acontece se fizermos o cdigo abaixo?

Pessoa minhaPessoa = new Pessoa();
Pessoa outraPessoa = minhaPessoa;

Os objetos minhaPessoa e outraPessoa so reference-types. Sendo assim, podemos
ilustrar a alocao do objeto minhaPessoa da seguinte maneira:

12

Agora, ns criamos um outro ponteiro, chamado outraPessoa, mas o igualamos ao objeto
minhaPessoa. Nesse ponto, o que vai acontecer, que na verdade o ponteiro outraPessoa vai
apontar exatamente para a mesma posio de memria que minhaPessoa est apontando...

13

Se ns j instanciamos o objeto atravs do minhaPessoa e outraPessoa vai apontar

exatamente para a mesma posio de memria que o minhaPessoa, isso quer dizer que
quando fazemos Pessoa outraPessoa = minhaPessoa, o objeto outraPessoa tambm j vai
estar instanciado: afinal, ele aponta para a mesma posio de memria que o objeto
minhaPessoa.

14

4. O padro MVC e o ASP.NET MVC

Desenvolver uma aplicao para a web no uma tarefa fcil Precisamos nos preocupar
mais com questes como segurana e performance em relao ao desenvolvimento de
aplicaes desktop por exemplo. Ainda h o fato de o ambiente de desenvolvimento de
aplicaes web ser completamente heterogneo, j que h a mistura da prpria linguagem a
ser utilizada (como o C# por exemplo) com linguagens prprias do ambiente web, como o
JavaScript e at mesmo o CSS, quando utilizado juntamente com LESS por exemplo.
Adicionando mais problemas a esse caos todo, ainda podemos esbarrar na organizao
do cdigo a ser escrito. Se, por muitas vezes, o cdigo de uma aplicao mais homognea,
como aplicaes desktop, j tende a ser bagunado, imagine um cdigo que mistura vrias
tecnologias como o caso de aplicaes web?
Talvez um dos maiores problemas para se organizar o cdigo de aplicaes web nem seja
a heterogeneidade envolvida com relao s linguagens, mas sim a diviso de
responsabilidades. Aonde que as regras de negcio devem ser tratadas? Onde devo tratar
a exibio de contedo e o HTML a ser exibido? Onde devo fazer a persistncia dos dados?
Para auxiliar nessa tarefa de organizao e separao de responsabilidades, ns podemos
empregar um design pattern muito conhecido pelos desenvolvedores de aplicaes web: o
MVC. MVC um acrnimo para Model View Controller. A inteno do MVC promover
uma organizao mais efetiva atravs da separao de responsabilidades, onde cada camada
responsvel por desempenhar um papel na estrutura da aplicao.
O papel de cada camada geralmente o seguinte:

Model: representa as entidades envolvidas em seu negcio e, no MVC puro, tambm
a camada responsvel pela persistncia. Por exemplo, se seu software um software
que administra o estoque de alimentos, provavelmente voc ter uma classe chamada
Alimento para representar cada alimento controlado por sua aplicao. Neste caso,
a classe Alimento um dos models de sua aplicao;
View: representa toda a parte de apresentao e exibio para o usurio. Ou seja,
nesta camada ficam os arquivos HTML, os arquivos CSS e eventualmente algum
arquivo JavaScript responsvel por controlar a interao do usurio;
Controller: como se fosse o crebro da aplicao, fazendo a ligao entre o model e
a view.

Como mencionado, o corao de uma aplicao MVC o controller. Quando disparamos
uma requisio (chamando uma pgina, por exemplo), o controller quem vai interpretar
nossa requisio e process-la, chamando as classes da camada model quando necessrio e
tambm chamando os arquivos HTML da camada da view.
Podemos representar esse esquema de comunicao entre as camadas com a seguinte
ilustrao:

15

Model

View

(Classes)

(HTML, CSS, JS)

Controller

Resposta HTTP

Requisio HTTP

(Response)

(Request)

Browser

(Chrome, Safari)

Perceba a diferena entre o modelo tradicional... O que pode ser nitidamente notado
que no chamamos mais as views diretamente: ns no chamamos um arquivo HTML, ns
vamos sempre chamar o controller e este se encarregar em chamar a view correspondente.
Na verdade, ns no chamamos diretamente o controller, mas sim um mtodo do
controller. Por exemplo, podemos ter um controller com um mtodo responsvel por
devolver uma view com a lista de todos os alimentos cadastrados. Provavelmente voc ter
os seguintes elementos em uma aplicao que siga a arquitetura MVC:

Um model para representar o alimento em sua aplicao. Provavelmente ser uma
classe chamada Alimento;
Um controller para fazer a ligao entre o model e a view de listagem. Provavelmente
este controller se chamar AlimentoController;
O AlimentoController provavelmente ter um mtodo que utilizar o model para
recuperar todos os alimentos cadastrados e enviar a listagem obtida para a view.
Geralmente, mtodos que servem para listar as coisas ns chamamos de
Index;
Tambm dever ter uma view responsvel por renderizar a lista de alimentos
retornada pelo controller. Geralmente, o arquivo que representa a view ganha o
mesmo nome do mtodo que interage com ela. Dessa maneira, teramos ento uma
view chamada Index.html.

Algo que importante ser destacado o formato da URL para se invocar ento um
mtodo de um controller. A URL geralmente tem um formato padro, descrito abaixo:

16





http://<servidor>/<controller>/<mtodo>


Dessa maneira, se quisssemos chamar o mtodo Index do AlimentoController
em um servidor localizado por www.meuapp.com.br, a URL teria o seguinte formato:

http://www.meuapp.com.br/alimento/index

A chamada para a URL acima dispararia o mtodo Index do AlimentoController no
servidor em www.meuapp.com.br. Por consequncia, o mtodo index do
AlimentoController se comunicaria com o model Alimento para obter a lista de todos
os alimentos cadastrados e repassaria para a view Index.html, para que esta ento
exibisse a listagem de alimentos obtida pelo controller. Logo aps a view processar esta
lista, ela seria devolvida como resposta para o browser que disparou a URL, fechando o
processo de renderizao da resposta.

Model

View

(Alimento)

(Index.html)

Controller

(AlimentoController/Index)

Index.html processado e com a lista de alimentos

http://www.meuapp.com.br/alimento/index

Browser

(Chrome, Safari)

importante salientar a terminologia de alguns elementos apresentados:
No padro MVC, a URL que utilizamos para chamar um mtodo de um controller
chamada de rota;
O mtodo do controller que invocado por uma rota tambm chamado de action.

O ASP.NET MVC segue exatamente este modelo, baseando-se em controllers, views,

models e actions. Os models e controllers so escritos com C# mesmo, utilizando-se
classes que herdam classes pr-determinadas. Por exemplo, no ASP.NET MVC, se
quisermos um controller, basta criarmos uma classe terminada em Controller e que
herda a classe Controller. Os models so classes convencionais. As views no ASP.NET
MVC no tm a extenso HTML, mas sim a extenso CSHTML. Este arquivo CSHTML um
HTML que pode ser misturado com cdigo C#, o que facilita o processo de interao com

17

o controller que tambm escrito em C#. Quando utilizamos os arquivos CSHTML,
tambm dispomos de uma srie de classes chamadas HTML Helpers, que reduzem
drasticamente o tempo de escrita da view. Tudo isso s possvel porque toda a parte de
visualizao do ASP.NET MVC implementada em cima de uma engine de visualizao
chamada Razor.

18

5. O protocolo HTTP

HTTP um acrnimo para HyperText Transfer Protocol, ou Protocolo de Transferncia de

HiperTexto. Trata-se de um protocolo que estabelece como deve ocorrer a comunicao
entre uma mquina cliente que faz pedidos para uma mquina servidora. Ele normatizado
por uma especificao, a RFC 2616.
Como j foi dito, o protocolo HTTP baseado na comunicao entre uma mquina cliente
que faz requisies para uma mquina servidora. Cada pedido que a mquina cliente faz para
o servidor chamado de requisio ou request; ao passo que a resposta do servidor para cada
pedido chamada de resposta ou response.
O protocolo HTTP utilizado desde a dcada de 90 em pginas e aplicaes Web. Neste
caso, quem faz o papel de cliente na histria o browser, o seu navegador. Hoje, os browsers
conseguem interpretar uma srie de protocolos, inclusive o HTTP.
Vamos a um exemplo: vamos acessar a pgina do Google. Se quisermos acessar a pgina
inicial do Google, devemos digitar em nosso navegador:

http://www.google.com.br

Acima, ns temos um HiperTexto, determinado por uma URL (Uniform Resource Locator
- Localizador de Recursos Uniforme). Perceba que de fato vamos utilizar o HTTP para fazer a
comunicao com o servidor do Google, pois a URL at se inicia com HTTP! Quando damos o
enter para que o browser processe a solicitao, uma requisio HTTP ento encaminhada
para os servidores do Google, onde ela ser processada.
Toda requisio HTTP composta basicamente por duas partes distintas: cabealho
(header) e corpo (body). O cabealho contm algumas informaes especficas da requisio,
como o browser que est fazendo a requisio, o tipo de resposta esperada do servidor e at
mesmo o tempo de timeout. J o corpo pode conter informaes adicionais que o cliente
pode enviar para o servidor que estaro atreladas requisio (request). O corpo no
obrigatrio, mas o cabealho .
Quando fazemos uma requisio para o Google, ns vamos ter o request similar ao
exibido abaixo:

19





Perceba que o cabealho da requisio envia para o servidor uma srie de informaes,
por exemplo:

A URL que gerou a requisio (Request URL);
O tipo de resposta esperada do servidor (Accept);
O idioma nativo do browser que disparou a requisio (Accept-Language).

Da parte do request, h uma informao importantssima que enviada no cabealho: o
mtodo de requisio (Request Method). Este dado do cabealho indica que tipo de ao a
URL que foi disparada para o servidor dever realizar, dando sentido semntico - ou seja,
significado - requisio. Os mtodos HTTP que podemos utilizar so: GET, POST, PUT,
DELETE, HEAD, OPTIONS, TRACE e CONNECT. Ns, na maioria do tempo, utilizamos mais os
mtodos GET, POST, PUT e DELETE. O significado destes mtodos est na tabela abaixo:

Mtodo Significado semntico
GET
Significa que queremos pegar algo no servidor: uma pgina, por
exemplo. Requisies GET fazem com que o servidor devolva algo para o
cliente, algo que estava dentro do servidor
POST
Significa que estamos querendo incluir alguma coisa no servidor. Por
exemplo, se temos uma pgina de cadastro de usurios, a requisio que
vai fazer com que o servidor faa o insert no banco de dados deve ser uma
requisio POST, afinal, estamos criando um novo item que vai ficar no
servidor
PUT
Significa que estamos querendo atualizar alguma coisa no servidor
DELETE Significa que estamos querendo apagar alguma coisa do servidor

Voltando requisio para o Google, verifique que uma requisio com o mtodo
GET. Isso significa que os servidores do Google devero retornar alguma coisa para o cliente
que disparou a requisio: neste caso, dever ser retornado o HTML da pgina inicial do
Google, para que o navegador (o nosso cliente neste caso) possa ento desenhar a pgina
para ns.

As respostas tambm possuem cabealho. Vamos analisar o cabealho da resposta do
servidor do Google.

20

Perceba que o servidor tambm retorna uma srie de informaes sobre ele. A resposta
tambm contm indicadores sobre o controle de cache que o browser dever executar
(cache-control), o tipo de resposta retornado pelo servidor (content-type) e at mesmo a data
em que a requisio foi processada no servidor. Agora, existe um item muito importante no
cabealho de resposta: trata-se do status da resposta. atravs deste status que o cliente
sabe se a requisio retornou sucesso ou se algo deu errado.
Os status HTTP tambm so padronizados pela especificao. Os principais status HTTP
que temos so:

Status Descrio
200
OK. Significa que o servidor entendeu a requisio e a processou sem
problemas.
302
Found. Significa que o recurso solicitado de fato existe no servidor (status
tpico de requisies GET)
401
Unauthorized. Significa que voc tentou acessar algum recurso do servidor
que exige autenticao para acesso, e voc ainda no realizou este processo.
404
Not Found. Significa que voc solicitou algum recurso no servidor que no
existe no lugar que voc indicou. Por exemplo: se voc tenta acessar alguma
pgina de algum site que no
Existe.
500
Internal Server Error. Significa que o servidor encontrou um erro durante o
processamento da requisio.

atravs destes status HTTP que o cliente sabe se a requisio que ele disparou deu certo
ou no.
O protocolo HTTP ainda possui algumas caractersticas que precisamos conhecer:

O protocolo HTTP stateless. Isso significa que ele no guarda estado. Por exemplo,
voc no consegue, somente com o protocolo HTTP, guardar se voc acessou
determinada pgina ou no, ou mesmo se um usurio fez o login em sua aplicao
web ou no. Isso ocorre porque as requisies HTTP so independentes entre si:
quando voc faz uma requisio, aberto um canal de comunicao com o servidor.
Por este canal, trafegada a requisio e a resposta. Logo quando o cliente recebe a

21

resposta, este canal imediatamente fechado (salvo algumas indicaes que
podemos fornecer no cabealho da requisio). Devido a isso, ele no pode guardar
estado, pois esse canal constantemente aberto e fechado, fora que as requisies
ocorrem de maneira isolada (uma requisio no sabe se existe alguma outra
requisio sendo feita ou no)... Existem estruturas que podemos utilizar para burlar
esta caracterstica do HTTP que veremos neste curso;
Como foi dito, o protocolo HTTP independente. Quando voc faz uma requisio
para o servidor, ela tratada de maneira isolada das demais requisies, sendo
impossvel fazer com que requisies se comuniquem umas com as outras. Por
exemplo: vamos imaginar que voc faz uma requisio para uma pgina HTML que
possui um texto e uma imagem. O navegador far no mnimo duas requisies para
carregar esta pgina: uma para recuperar o texto e outra para recuperar a imagem.
Porm, apesar de ambas as requisies serem necessrias para montar uma nica
pgina, o servidor as entender de maneira completamente isolada, cabendo ao
cliente juntar ambas as respostas para montar a pgina solicitada;
O protocolo HTTP assncrono, ou seja: voc pode fazer vrias requisies ao mesmo
tempo. Como estas requisies so independentes, elas tambm sero tratadas ao
mesmo tempo. O servidor tambm ir devolver as respostas no necessariamente na
mesma ordem em que as requisies foram realizadas, ele ir devolver medida que
o processamento for sendo finalizado.

22

6. Persistncia de informaes e a impedncia

difcil construirmos uma aplicao que no necessite armazenar informaes em algum

lugar. Um dos meios mais utilizados para persistncia de informaes por parte das aplicaes
so os bancos de dados relacionais.
Porm, existem algumas barreiras tcnicas ocasionadas pela utilizao de bases de dados
relacionais para armazenamento de informaes. Estas barreiras ocorrem basicamente pelo
fato de que softwares modernos so desenvolvidos seguindo-se o paradigma orientado a
objetos, enquanto bancos de dados relacionais seguem o paradigma relacional. Enquanto no
modelo orientado a objetos o foco criar estruturas que possibilitem a representao do
mundo real dentro das linhas de cdigo de um projeto de software, o paradigma relacional
d foco s relaes entre entidades e consistncia das informaes. Sendo assim, o modelo
orientado a objetos no compatvel naturalmente com o modelo relacional, exigindo um
esforo de converso do modelo orientado a objetos para o modelo relacional e vice-versa.
A este esforo de converso, bem como as barreiras tcnicas que ocorrem devido
incompatibilidade entre os modelos orientados e relacionais chamada de impedncia
objeto-relacional (em ingls, object-relational impedance mismatch).

Alguns problemas caractersticos da impedncia so:

Diferenas entre tipos de dados: em bases relacionais, um tipo de dado que pode
ser utilizado para representar nmeros inteiros (sendo INT, NUMBER ou qualquer
outro) no tem as mesmas caractersticas de tipos inteiros em linguagens
orientadas a objeto. Essas caractersticas podem ser o intervalo de nmeros entre
os modelos relacional e orientado a objeto que so diferentes, ou mesmo o
comportamento com nmeros negativos. Outro tipo de dado que sofre direrenas
entre os modelos relacional e orientado a objeto so as strings. Enquanto no
modelo relacional elas possuem a possibilidade de delimitao (em um banco de
dados, voc pode limitar um campo VARCHAR para suportar no mximo 100
caracteres por exemplo), o modelo orientado a objeto no oferece a possibilidade
de se atribuir esse tipo de limitao s strings. Em suma, o sistema de tipagem de

23

dados de bases relacionais e linguagens orientadas a objeto so completamente
diferentes um do outro;
H uma grande diferena com relao integridade de dados entre o modelo
relacional e o modelo orientado a objetos: a maneira como as estruturas se
relacionam. Em linguagens orientadas a objeto, ns temos a menor unidade como
sendo um objeto, que pode ser composto por outros objetos ou se relacionar a
outros objetos (seja por associao ou composio). Em bases relacionais, no
existe essa possibilidade: a menor unidade uma tupla de uma tabela, que segue
um modelo rgido definido de acordo com os campos da tabela. O relacionamento
feito com outras estruturas feito com base em chaves estrangeiras. Ou seja: o
modelo relacional enfatiza a maneira como um objeto conversa com o outro, o
modelo relacional d enfoque s relaes;
H tambm problemas relacionados visibilidade de estruturas. Em linguagens
orientadas a objeto, existem os conceitos de public, private e protected, o que
permite utilizao de tcnicas como o encapsulamento. O modelo relacional no
oferece nada nesse sentido. Isso um problema, pois muitas vezes necessrio
se inserir uma informao que no acessvel de maneira pblica em um objeto
para uma coluna em um banco de dados;
H uma diferena enorme com relao estrutura entre o modelo orientado a
objeto e o modelo relacional: o modelo orientado a objetos lida com classes,
interfaces, herana e por a vai. O modelo relacional no oferece esse tipo de
estrutura: em bancos de dados, ele se resume tabelas, ndices e chaves primrias
e estrangeiras. H uma enorme diferena estrutural entre os elementos destes
dois paradigmas.

Sendo assim, necessrio fazer a converso do modelo relacional para o modelo
orientado a objetos quando nossa aplicao l informaes de um banco de dados e viceversa quando nossas aplicaes enviam informaes para um banco de dados. Abaixo
podemos ver um exemplo de um cdigo que realiza essa converso: trata-se da leitura de
uma tabela utilizando-se ADO.NET puro.

string connectionString = ;
List<Pessoa> pessoas new List<Pessoa>();
using
(SqlConnection
connection
=
new
SqlConnection(connectionString))
{
connection.Open();
using (SqlCommand command = new SqlCommand("SELECT * FROM
PESSOAS", connection))
{
SqlDataReader reader = command.ExecuteReader();
while (reader.Read())
{

24

Pessoa p = new Pessoa

{
Id = Convert.ToInt32(reader[ID]),
Nome = reader[NOME_PESSOA].ToString()
};
pessoas.Add(p);
}
}
}

Perceba o trecho que a impedncia tratada: dentro do while que trata a leitura do
DataReader, as informaes so extradas do modelo relacional para o modelo orientado a
objetos, j que um objeto do tipo Pessoa criado e abastecido com as informaes obtidas
de um banco de dados. Porm, essa no uma maneira interessante de se realizar a
converso ente os modelos relacional e orientado a objeto, pois uma maneira muito
manual. Alm de que, se a tabela PESSOAS sofrer qualquer tipo de alterao em sua
estrutura, isso pode causar a quebra do cdigo que realiza a leitura da tabela PESSOAS e faz
a converso para um objeto do tipo Pessoa. O ideal era ter algum tipo de framework para
fazer a converso de maneira mais automatizada. E a entram os frameworks ORM.
ORM um acrnimo para object-relational mapping mapeamento objeto-relacional.
Trata-se de um tipo de framework que visa auxiliar na reduo da impedncia, realizando
todas as converses necessrias entre os modelos relacional e orientado a objeto de maneira
automatizada. Frameworks ORM tratam as converses entre as estruturas relacionais para as
estruturas orientadas a objeto geralmente da seguinte forma:

Cada classe acaba sendo interpretada como uma tabela;
Cada linha de uma tabela, bem como seus relacionamentos, tratada como
instncia do objeto relacionado tabela em questo.

Frameworks ORM tambm visam retirar a necessidade de o desenvolvedor de software
se preocupar com linguagem SQL, bem como as converses necessrias entre os diferentes
tipos de dados. O desenvolvedor sempre programa no paradigma orientado a objeto,
inclusive quando h a necessidade de se fazer manipulao e leitura de informaes a partir
de uma base relacional. Todo este trabalho, inclusive a gerao dos comandos SQL
necessrios, fica a cargo do framework ORM. E, na plataforma .NET, temos um representante
de peso nesse segmento: o Entity Framework.
O Entity Framework framework ORM fornecida pela prpria Microsoft. Ele uma
implementao do ADO.NET em conjunto com o LINQ, mais especificamente utilizando o
provider LINQ to Entities (LINQ para entidades). Atualmente, h providers para os principais
bancos de dados do mercado para o Entity Framework, ou seja: possvel utilizar o Entity
Framework com SQL Server, Oracle, MySQL, PostGres e outros bancos de grandes players
disponveis no mercado.
O Entity Framework um projeto open source, tambm fazendo parte da .NET
Foundation (http://www.dotnetfoundation.org). O cdigo-fonte, bem como a abertura e
acompanhamento de bugs e issues, est atualmente no Codeplex, no endereo

25





http://entityframework.codeplex.com. Porm, a tendncia que com o tempo o projeto seja
migrado para o GitHub, assim como alguns outros projetos da .NET Foudation. Para utilizao
nos projetos, o Entity Framework disponibilizado via pacote NuGet.
possvel utilizar o Entity Framework para todos os templates de projeto da plataforma
.NET, desde Windows Forms at projetos Web (MVC e WebForms), passando at por
aplicaes Console. No h restrio com relao plataforma para utilizao do Entity
Framework. A restrio para utilizao do Entity Framework na verdade se encontra do banco
de dados que ser utilizado: deve haver um provider para o Entity Framework relacionado ao
banco de dados com o qual se deseja trabalhar. Porm, como dito anteriormente, a grande
maioria dos bancos de dados comerciais j possuem providers para o Entity Framework.
O Entity Framework nos fornece trs modos de trabalho:

Code First: permite trabalhar sem a necessidade de se executar configuraes,
seja de mapeamento ou de ambiente. A idia o desenvolvedor simplesmente
escrever as classes desejadas como classes POCO e depois acrescent-las
estrutura do Entity Framework, deixando este responsvel por fazer a converso
para a criao das estruturas necessrias no banco de dados;
Model First: permite que voc crie suas classes de domnio e tambm as estruturas
necessrias no banco de dados a partir de um arquivo XML de mapeamentos. No
caso de utilizao do Entity Framework, esse arquivo possui a extenso EDMX -
;Entity Data Model XML. Quando o arquivo EDMX modificado, estas
modificaes so convertidas em classes POCO e tambm em estruturas (tabelas,
ndices...) no banco de dados de destino;
Database First: permite que as classe POCO sejam geradas a partir de um banco
de dados existente. O Entity Framework faz a engenharia reversa da base de dados
no qual ele se conecta, convertendo as tabelas em classes para serem utilizadas
no paradigma orientado a objetos.

POCO um acrnimo para Plain-Old CLR Objects. Tratam-se de classes desacopladas
de qualquer framework. Classes POCO so classes simples, com somente suas propriedades,
seus mtodos assessores e nada mais. Ou seja, objetos POCO so objetos planos.

26