Translate this page now :



»Programação
»Programação.NET
»Banco de Dados
»Webdesign
»Office
» Certificações Microsoft 4
»Treinamentos4
»Programação 4
»Webdesign«
»Office & User Tips«
»Grupos de Usuários
»Células Acadêmicas«
intcontpiada : 118
Cachorrada na Net
Você já está cadastrado e participa do grupo de usuários de sua cidade ? Se não, comente o porque.
 
 
Faça um pequeno teste com 10 questões de VB
.:.
Teste seus conhecimentos em Visual Basic, SQL Server e ASP 3.0 com nossas provas on-line
.:.
Aprimore seus conhecimentos em programação com nosso treinamento on-line de lógica de programação
.:.
Veja nosso calendário de treinamentos
Gostou da Página?
Então

para um amigo!
 





Por Dennes Torres
dennes@bufaloinfo.com.br
Dennes Torres possui as certificações MCAD, MCSD,MCSE, MCDBA e MCT. Atualmente atua Como diretor da Búfalo Informática, líder do grupo de usuários DevASPNet no Rio de Janeiro e membro da liderança dos grupos getWindows e devSQL, também do Rio de Janeiro, podendo sempre ser encontrado na lista de discussão do grupo DevASPNet (devaspnet-subscribe@yahoogrupos.com.br) bem como nas reuniões do grupo. Mantém dois blogs em http://cidadaocarioca.blogspot.com

Analisando o ASP.NET MVC Framework

Pesquisa personalizada
Pesquisar Dicas:






A versão 3.5 do Framework .NET foi lançada este ano, mas o que muitos não sabem é que o ASP.NET desvinculou seu versionamento do versionamento do framework .net.

Em 2005 foi lançado o ASP.NET 2.0 em conjunto com o framework 2.0, então framework e ASP.NET caminhavam juntos. Já em 2006, quando a Microsoft lançou o framework 3.0, não houve nenhum lançamento de ASP.NET 3.0 - não existe nem vai existir ASP.NET 3.0.

No final de 2007/inicio de 2008 a Microsoft lançou o framework 3.5 e mais uma vez não tivemos lançamento do ASP.NET. Assim sendo, o framework 3.5 - Visual Studio 2008 - continua trabalhando com ASP.NET 2.0.

Porém a Microsoft já está trabalhando há algum tempo na versão 3.5 do ASP.NET e o lançamento desta versão está prometido ainda para este ano. As grandes novidades do ASP.NET 3.5 serão o ASP.NET Dynamic Data e o ASP.NET MVC Framework. Portanto nesse conjunto de artigos vamos abordar o ASP.NET MVC, recurso da versão 3.5 do ASP.NET, que ainda encontra-se em beta.

Este artigo não é para explicar o funcionamento do ASP.NET MVC Framework, para isso você pode experimentar o artigo Criando uma Cesta de Compras com o ASP.NET MVC . Neste artigo iremos analisar a teoria de sua utilização.

Já abordamos anteriormente uma metodologia de trabalho em camadas para o framework 1.1 e uma metodologia de trabalho em camadas para o framework 2.0, esta também em vídeo. O padrão MVC nada mais é do que um design pattern para trabalho em camadas, as vezes bem interpretado, as vezes não, conforme mostrarei no artigo a seguir.

O ASP.NET MVC tem sido apresentado ao mercado como uma alternativa de desenvolvimento ao modelo de webForms.

O que tentarei analisar aqui neste artigo é : ASP.NET MVC Framework ou Web Forms ?

Não, este artigo está longe de querer cair nas eternas análises de quem é melhor, "A" ou "B" . O próprio fabricante afirma que um modelo não irá substituir o outro, mas que ambos irão coexistir. A questão é : Se o próprio fabricante afirma isso, então cada um dos modelos deve ter sua razão de ser, deve ter seu cenário, sua situação em que cada um se sai melhor, dai este artigo.

Vamos fazer em um estilo meio de perguntas e respostas para ficar mais simples a análise. No texto abaixo vou analisar em detalhes o que foi exposto no artigo de Chris Tavares na MSDN Magazine, ele participa bem de perto do desenvolvimento do MVC Framework.

O ASP.NET MVC Framework tem alguma pretensão atual ou futura de substituir os webForms ?

De forma alguma. A Microsoft jura de pé junto e sem nenhum dedo cruzado que nunca pensou nesta possibilidade. O MVC Framework é apenas uma alternativa adicional para o desenvolvimento. Alguns vão preferir desenvolver com WebForms, outros vão preferir desenvolver com o MVC Framework, vira uma questão de gosto (será?).

Existe algo que o MVC Framework faça e que os webForms não façam ?

Cada pessoa irá responder esta pergunta das formas mais variadas possíveis, sempre afirmando positivamente, claro (claro?). Vamos analisar as formas mais comuns :

A testabilidade do MVC Framework é maior do que nos webForms

Essa realmente é indiscutível. O MVC Framework possui uma espécie de simulador de ambiente web, digamos assim. Então se uma página chama request.form, por exemplo, no MVC Framework isso é tratado por um ambiente simulado que fornece uma resposta (que pode ser controlada por você). Não existe nada semelhante para o ambiente de web forms.

Isso não quer dizer que não seja possível realizar testes com webForms, é perfeitamente possível, apenas não se discute, pelo menos por enquanto, que os testes sejam mais simples no MVC Framework

Em seu artigo, Chris explica como através da criação da Web Client Software Factory (WCSF), fez com que os webforms ganhassem maior testabilidade (palavrinha que está virando moda) através da implementação do padrão MVP - Model View Presenter.

O padrão MVP é um padrão através do qual a view desconhece diretamente o presenter (que faz o papel de controller), a view e o presenter apenas são ligados por uma interface de conhecimento comum. Compare os gráficos demonstrando um padrão MVC e um padrão MVP (em teorica acadêmica, digamos) :

 

(gráficos obtidos no site da Infragistics)

O padrão MVP é bem mais complexo de ser produzido, mas como resultado gera um sistema dividido em partes mais independentes do que o próprio padrão MVC.

Um ponto interessante é que as views se interligam ao controller/presenter através de eventos, sempre com a view disparando um evento que será recebido pelo controller. Neste caso, por que muitos vêem como algo tão ruim a view (aspx) ser o ponto de inicio do processamento no ASP.NET, tendo motivado assim a geração do framework de ASP.NET MVC?

Minha opinião : A visão teória do MVP e do MVC são bonitinhas, mas só usaria tais visões em algum caso muito específico em que a necessidade surgisse. Prefiro o gráfico mais abaixo (calma, não precisa correr para a barra de rolagem, daqui a pouco chegamos lá) criado pelo Macoratti e que muito se assemelha aos gráficos que eu próprio demonstro durante treinamentos e palestras.

É muito interessante, porém, destacar este trecho existente no artigo do Chris :

"Desde que vim trabalhar na Microsoft, tive a oportunidade de compartilhar o meu conhecimento sobre vários pontos problemáticos e, felizmente, de resolver em parte esses problemas. Mais recentemente, surgiu uma oportunidade como essas por meio da minha participação como desenvolvedor no projeto Web Client Software Factory ( codeplex.com/websf ) das diretrizes. Em especial, uma das coisas que as diretrizes incorporam a seus resultados finais é o teste de unidade automatizado. No Web Client Software Factory, propusemos o uso do padrão MVP (Model View Presenter) para criar Web Forms que pudessem ser testados.

(...)

O MVP funciona, mas a implementação pode ser um pouco esquisita; você precisa de uma interface de exibição separada, sendo necessário escrever muitas funções de encaminhamento de eventos nos arquivos code-behind. Mas, se quiser uma interface do usuário que possa ser testada nos aplicativos dos Web Forms, isso é o melhor que você conseguirá. "

Porém o Chris deixa de lado duas questões importantes, quando pelo menos uma delas ele poderia ter concluido :

A escolha de usar o padrão MVP ao invés do MVC gerou a maior complexidade da qual o Chris reclama em seu texto. A testabilidade seria obtida muito bem com o padrão MVC, o MVP seria mais recomendado para ambientes extremamente dinâmicos (worksflows talvez). Portanto podia ser mais simples e ter maior testabilidade sem chutar o balde.

O webcast que fiz que tem sido mais assistido é o de criação de uma camada de acesso a dados na web. Neste webCast demonstro como é perfeitamente possível trabalhar em camadas na web utilizando RAD ao extremo sem perder a capacidade de manutenção. Testabilidade não é comentada mas basta assistir e poderá observar que o nível de testabilidade também é bem alto.

É óbvio (assistindo-se ao webcast) que perde-se a independência de banco de dados, mas a diferença de produtividade é tão grande que é um fato a se analisar com cuidado. Se ao fim decidir-se por um padrão mais trabalhoso para se ganhar a independência de banco então o padrão mais trabalhoso foi escolhido por causa disso e não pela testabilidade ou porque não pudesse ser mais simples.

 

Maior separação de regras de negócio da interface

Não existe comprovação deste argumento. É fato que o MVC, como padrão, garante esta maior separação, mas a questão é : Era realmente necessário mudar por completo a arquitetura da tecnologia para que se encaixasse perfeitamente com o padrão MVC, ou seria possível chegar aos mesmos resultados do padrão MVC usando o padrão como guia e os webForms como tecnologia ?

Já analisei diversos artigos que tentam comparar o ASP.NET MVC Framework aos WebForms e a grande maioria (para não dizer quase todos) comparam o ASP.NET MVC Framework com formas erradas de uso dos webForms. O artigo do Chris é sem dúvida o mais preciso em termos de comparação. Mesmo com toda a precisão, em seu inicio o artigo cita "É muito sedutora a idéia de apenas jogar a lógica do aplicativo nos manipuladores de evento da página (de maneira muito semelhante ao Visual Basic ® habilitado para aplicativos do Windows). ". Felizmente este artigo (do Chris) avança na comparação e, ao contrário de outros, não fica preso na comparação apenas com o uso errado dos webForms.

Se os webForms forem utilizados de forma correta, com uma adequada separação em camadas, em que ponto ficaria essa diferença em relação a separação de camadas ?

Existem exemplos que poderiam comparar ambos mas, até por serem por demais trabalhosos, não temos nenhum tipo de comparação publicada com exemplos assim :

Cores : Que tal um exemplo no qual, devido a regras de negócios, seja necessário exibir elementos com cores diferentes na tela ? Como separar as regras de negócio da interface ?

Page Flow : Exemplos que necessitem de um controle de fluxo entre as páginas envolvem muitas regras de negócio fortememte acopladas com a interface.

No final, não se sabe como os webforms ou o MVC Framework se sairiam ao lidar com exemplos complexos como esses.

O padrão MVC, porém, existe desde muito antes do MVC Framework e já era aplicado, e muito bem aplicado, nos webforms do ASP.NET.

Procurando imagens que representem o padrão MVC a melhor que encontrei foi no site do Macoratti, vejam :

Algumas observações importantes sobre este desenho :

Ele representa, sem problema algum, situações em que a view é o ponto de inicio de uma chamada no modelo MVC, nem por isso deixa de ser MVC.

A separação de camadas é clara

A testabilidade é obtida facilmente dos componentes na camada de controle e na camada de modelo e com alguma dificuldade a mais na camada de visualização

A camada de modelo se divide em mais de uma

Quem afirmar que a imagem está distorcida e não representa corretamente o pattern de MVC, entre no google e procure uma imagem sobre o pattern de MVC. Observe como para cada ambiente tecnológico temos representações diferentes - Java, RoR, ASP.NET, PHP, o pattern é adaptado ao ambiente tecnológico ao qual é aplicado, tendo variações em cada ambiente.

Com a criação do ASP.NET MVC o que está acontecendo é o contrário, o ambiente tecnológico está sendo adaptado ao pattern. Será que deveria ser feito assim ?

Um outro ponto interessante e que também demonstra como o MVC pode aparecer de diversas formas diferentes, é o gráfico que costumo apresentar em aulas e palestras sobre o desenvolvimento em camadas no .NET (cheguei a citar no webCast de camadas e no webCast sobre orientação a objetos)

Junto com esse gráfico explico o conceito de processo (termo que gerei para identificar isso), uma ação que envolve vários assuntos de negócio e que muitas vezes precisa ser transacional. Observem como o processo não só faz o papel do controler, mas nesta demonstração fica bem mais clara sua funcionalidade e necessidade.

Outra diferença no gráfico é o fato de nem sempre o processo estar presente. Nem todas as ações de uma view requerem um processo com vários assuntos de negócio, as vezes um assunto de negócio já basta. Sou adepto de que o processo não deve ter função burocrática, de apenas receber e repassar pedido. Se há inteligencia, que ele fique, se não há, não deve estar lá.

Utilização ampla de REST

Isso é apenas impressão. O fato é que o namespace que possui os recursos para mapeamento de URLs e uso de REST não é interno ao MVC framework, pelo contrário, foi criado como um namespace a parte para poder ser utilizado tanto pelo framework MVC como pelos webForms.

Maior exigência de aderência ao MVC Framework

A suposta vantagem pode também ser vista como desvantagem no sentido de amarrar o desenvolvedor a uma forma de desenvolvimento.

Piora um pouco mais se considerarmos que em alguns casos o MVC Framework chega a incentivar a mistura de código com tags, um problema que já não tinhamos a muito tempo e que o padrão MVC deveria justamente eliminar, a mistura entre interface e negócio.

Assim sendo, sobre o pretexto de forçar a aplicação do MVC, o MVC Framework abre inúmeras outras possibilidades do programador fazer bobagens igualando-se neste ponto aos webForms.

A pergunta anterior também é válida : Será certo adaptar a tecnologia ao pattern, ou seria preferível que continuassemos adaptando o pattern a tecnologia, como foi feito até hoje ?

Maior controle sobre o HTML

Neste tópico pode-se debater muito mais, focando-se especialmente em abstração.

Afinal de contas, quantos motoristas conhecem em absolutos detalhes as peças e o funcionamento do motor de seus carros ?

Nesse sentido, até quando teremos esse grande desejo de controlar em detalhes todo o nosso HTML ?

É absoluta verdade que o Visual Studio 2005 não foi uma grande maravilha para o design gráfico, mas será que isso justifica deixar de lado um ambiente com recursos tão numerosos para a produtividade do desenvolvimento em troca de um maior controle do design gráfico ?

Mais um complicador na equação são os diferentes pontos de vista existentes. Para um desenvolvedor de soluções complexas nas quais existem muitas regras de negócio, o total controle do HTML é algo que ele absolutamente não deseja. Já para o designer que encontra-se construindo alguns sites simples, controlar o HTML é o seu trabalho.

Da minha parte, preferiria ambos : Um bom controle do HTML - quando necessário - sem ficar limitado tecnologicamente em relação a abstração. Em minha opinião o Visual Studio 2008 e o atual ASP.NET conseguem isso (veja este webcast)

Outro ponto nesta equação é o fato de que estamos muito, muito longe da abstração absoluta. Temos vários recursos para manipular a saida HTML em baixo nível, vejam :

Attributes : Todos os objetos possuem a propriedade attributes, que permite total controle sobre os atributos que serão renderizados em suas tags

clientID : Contém o nome que o objeto terá quando estiver no client. Se for utilizado corretamente, está muito longe de gerar o martírio no desenvolvimento javascript do qual muitos desenvolvedores acusam o .NET

Control Adapters : Pode-se criar control adapters para qualquer web control no .NET, sendo que o control adapter possui a capacidade de mudar a forma final de saida do html do web control

Eventos PreRender/Render : Permitem interceptar a geração do HTML e altera-lo

Considere-se ainda o benefício na abstração do design (Skin/Themes) e na abstração do javascript (criar novos webcontrols já com javascript adequado) e temos mais benefícios do que problemas.

Este é, sem dúvida, um dos tópicos mais polêmicos a respeito dos webForms e voltaremos a ele em seguida.

Existe algo que os webForms possam fazer que o framework MVC não possa fazer ?

Os webforms fazem um controle de estado, controle de dados através dos postbacks, utilizando o viewstate, um campo oculto na página. Isso é excelente em termos de abstração, o desenvolvedor deixa de se preocupar com pequenos detalhes da web e passa a se preocupar mais com as funcionalidades de sua aplicação.

O Framework MVC não faz controle de estado automaticamente, então todo controle de estado que se torne necessário precisa ser feito pelo próprio desenvolvedor, que irá trabalhar em mais baixo nível - com menos abstração - para isso.

Por esse motivo nenhum webControl que necessite de controle de estado ou de postback (também não suportado no framework MVC) irá funcionar neste ambiente. Conseguem pensar em alguns ?

Os que são radicalmente contra os webForms vêem o controle de estado - o viewState - como parte do lixo gerado pelos webForms. O artigo do Chris cita isso, mas faltam demonstrações de um projeto onde o controle do ViewState seja tão perturbador como afirma o Chris e que, feito com o ASP.NET MVC Framework, o projeto fique muito melhor.

Ao contrário do Chris, muitos se esquecem de que o desenvolvedor tem total controle sobre o viewstate, podendo alterar sua localização bem como desliga-lo, além da ferramenta de trace que exibe em detalhes quantos bytes cada webControl gasta no viewstate. Também não explicam em detalhes como fariam para manter estado de forma equivalente com a segurança e versatilidade de ter um hash e poder ser criptografado.

Os webForms possuem controle de eventValidation. Aplicações web são por natureza muito expostas e possuem um grande número de pontos de ataque. Este alto número de pontos de ataque vai contra a lógica tradicional do desenvolvedor, em especial o desenvolvedor vindo de um ambiente windows. O eventValidation, um campo oculto nos webForms, garante a proteção da aplicação webForm contra tentativas de invasão nos pontos de ataque que passam despercebidos ao desenvolvedor. O Framework MVC não possui nada semelhante, existindo então a necessidade de que algo seja produzido nesse sentido.

Como citamos antes, webcontrols que exijam postbacks não funcionam no framework MVC. Inclua então gridview, formview, entre muitos outros. Todo o trabalho desses webControls passa a ter que ser reproduzido manualmente.

Fica sem sombra de dúvida, neste caso, uma diferença de produtividade entre webforms e framework MVC, sendo que ao falar desta diferença não me refiro apenas a curva de aprendizado, que seria outro problema, mas sim uma diferença mesmo de produtividade, tal qual o ASP clássico e o atual ASP.NET

Vale a pena trocar produtividade por testabilidade ?

Se levada ao pé da letra, a pergunta parece por demais crítica : Vale a pena trocar velocidade em desenvolvimento por qualidade ?

Porém ao analisarmos esta pergunta devemos lembrar que não sabemos qual o tamanho da diferença de que estamos falando. É possível testar webForms, isso sabemos. Então podemos ter a produtividade dos webForms com testes, podemos. Mas a testabilidade do Framework MVC é maior, mas é maior o suficiente para eliminar a diferença de produtividade ?

Não existem exemplos, não existem demonstrações a esse respeito e isso sem dúvida é algo de que precisamos.

Alguns chegam a afirmar que a testabilidade, e por isso o framework MVC, são essenciais a ponto da troca ser válida. Mas como essas pessoas desenvolviam para a web antes ?

Apesar de não ser uma real troca, já que os testes vão existir em ambos os casos, é importante que o desenvolvedor esteja atento a esta análise, que é extremamente subjetiva.

Conclusão

Minha opinião em relação ao Framework de ASP.NET MVC hoje não é muito positiva. Que fique claro que é em relação ao Framework de ASP.NET MVC e não ao padrão MVC.

O Framework de ASP.NET MVC traz algumas coisas boas e a melhor delas é sem dúvida a testabilidade com a capacidade de simular um contexto web, mas em minha opinião isso está longe de torna-lo um recurso válido para o ambiente de produção.

Com relação ao padrão em si, demonstrei mais acima que ele tem se adaptado a cada tecnologia na qual é implementado. Em minha opinião não é boa prática se prender a um padrão simplesmente por ser padrão. O ideal é modelar seus sistemas com base nos seus requisitos de negócio, tendo em mente a produtividade, capacidade de manutenção e testabilidade.

Modelado o sistema (estamos falando de análise, não de execução), padrões como MVC e MVP podem ser utilizados para validar o modelo e garantir que nada foi esquecido.

Observações Finais

É claro que esse assunto irá gerar um grande debate. Inscreva-se no grupo de usuários devASPNet enviando um e-mail para devASPNet-subscribe@yahoogrupos.com.br e sinta-se a vontade para debater esse tema conosco



Envie seus comentários sobre este artigo

Nome :

E-mail :

Comentários :


Avise-me quando houverem novos comentários nesta página

Veja abaixo os comentários já enviados :

Nome : Celso E-Mail : ceelssso@hotmail.com
Adorei o artigo. Muito bom pra quem esta analisando se vai usar Web Forms ou MVC em um projeto.

[]s
Nome : 1 E-Mail : 1
-1'
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1