1. O documento apresenta uma visão geral das tecnologias .NET Framework 4.0, ASP.NET MVC 3 e Silverlight 4, discutindo seus principais recursos e como foram integradas para desenvolver um aplicativo de demonstração. 2. É descrita a estrutura do projeto incluindo domínio, infraestrutura e camada web com ênfase na integração das tecnologias. 3. Também são discutidas vantagens, desvantagens e estilos arquiteturais de cada tecnologia.

1. Pontifícia Universidade Católica de Minas Gerais
Programa de Pós-Graduação em Engenharia de Software
Relatório Técnico:
.NET Framework, ASP.NET MVC 3 e
Silverlight
Belo Horizonte
2011

2. Alexandre Pacheco
Anne Kelly
Diógenes Peçanha
Glauco Vinicius
Gustavo Veloso
Karla Lages
Relatório Técnico:
.NET Framework, ASP.NET MVC 3 e
Silverlight
Belo Horizonte
2011

3. Sumário
1 Introdução 2
2 Visão Geral das Tecnologias Envolvidas 3
2.1 .NET Framework 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 ASP.NET MVC 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Silverlight 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Visão Geral dos Padrões Envolvidos 5
3.1 WCAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Integração 6
4.1 Ambiente de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Estrutura do Projeto - Domínio . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1 Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.2 Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.3 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Estrutura do Projeto - Infra-Estrutura . . . . . . . . . . . . . . . . . . . . 9
4.3.1 Captcha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.2 Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.3 InfraService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4 Estrutura do Projeto - Web . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4.1 Captcha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5 Projeto Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5.2 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5.3 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5 Vantagens e desvantages 13
5.1 Vantagens e desvantagens do .NET Framework 4 . . . . . . . . . . . . . . . 13
5.1.1 Vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.2 Desvantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2 Vantagens e desvantagens do ASP.NET MVC 3 . . . . . . . . . . . . . . . 13
5.2.1 Vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.2 Desvantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3 Vantagens e desvantagens do Silverlight . . . . . . . . . . . . . . . . . . . . 14
5.3.1 Vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3.2 Desvantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4 Vantagens e desvantagens do WCAG . . . . . . . . . . . . . . . . . . . . . 15
5.4.1 Vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4.2 Desvantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6 Principais cenários de uso 15
6.1 ASP.NET MVC 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2 Silverlight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4. 7 Estilos Arquiteturais 15
7.1 Client / Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2 Arquitetura baseada em componentes . . . . . . . . . . . . . . . . . . . . . 16
7.3 Arquitetura em camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.4 N-Tier / 3-Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.5 Orientado a Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.6 Apresentação Separada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8 Casos de uso reais no Brasil 17
8.1 ASP.NET MVC 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2 Silverlight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9 Depoimento de usuários real da tecnologia 17
9.1 Entrevistado 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2 Entrevistado 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2

5. 1 Introdução
Este relatório destina-se à compreensão dos conceitos arquiteturais relativos as tec-
nologias ASP.NET MVC 3 e Silverlight 4, ambas suportadas pelo .NET Framework 4.0.
Perguntas como O que são essas tecnologias? , Quais seus pontos positivos e negativos?
e A quem se destina? serão respondidas ao longo das páginas que se seguem.
Uma demonstração foi desenvolvida a partir do caso de uso Cadastro de Usuários da
Gonzo University , visando uma abordagem conjunta das tecnologias citadas. As di-
culdades e as facilidades encontradas na construção do aplicativo de demonstração serão
apresentadas na tentativa de mitigar os riscos inerentes à adoção de um novo conjunto de
tecnologias em projetos do mundo real.
2

6. 2 Visão Geral das Tecnologias Envolvidas
2.1 .NET Framework 4.0
O .NET Framework é uma plataforma da Microsoft para desenvolvimento de aplica-
ções criada tendo, principalmente, os seguintes objetivos em vista:
• Prover um ambiente de programação orientada a objetos consistente, onde código-
objeto é armazenado e executado localmente, podendo ser facilmente distribuído
pela Internet, ou executado remotamente.
• Prover um ambiente de execução de código que minimize conitos de versionamento
e publicação.
• Prover um ambiente de execução que promova execução segura de código, incluindo
código criado por desconhecidos ou terceiros.
• Prover um ambiente de execução que elimina os problemas de performance das
linguagens de script ou interpretadas.
• Criar uma experiência consistente para o desenvolvedor através dos mais variados
tipos de aplicações, como aplicações baseadas no Windows e aplicações Web.
• Construir toda a interoperabilidade, sobre padrões da indústria, para garantir que
qualquer código que rode sobre o .NET Framework seja capaz de se integrar com
qualquer outro código.
Figura 1: Visão geral do .NET Framework e de seus principais componentes.
3

7. 2.2 ASP.NET MVC 3
O padrão Model-View-Controller (MVC ) é um estilo arquitetural que separa os com-
ponentes de interface gráca de uma aplicação. A separação dá mais controle sobre as
partes individuais da aplicação, incentivando o desenvolvimento mais simples, produzindo
código manutenível e testável.
O ASP.NET MVC é uma implementação do estilo arquitetural MVC para o framework
ASP.NET, cujo objetivo é fornecer uma alternativa ao padrão Web Forms, disponível até
então, e não um substituto, como muitos podem imaginar.
Uma aplicação Web criada utilizando-se o framework ASP.NET MVC é composta
pelos seguintes componentes:
• Models : São parte da aplicação que implementam a lógica para os dados de domínio
da aplicação. Em aplicações pequenas, o modelo é frequentemente uma separação
conceitual ao invés de uma separação física.
• Views :São os componentes que exibem a interface de usuário da aplicação. Tipi-
camente, a interface de usuário é criada a partir dos dados do modelo.
• Controllers : São os componentes que lidam com as interações dos usuários, traba-
lham com o modelo, e nalmente selecionam a view a ser renderizada para exibir a
interface de usuário. Em uma aplicação MVC, a View apenas exibe informação que
o Controller lida e responde as entradas e interação do usuário.
Figura 2: Principais componentes do estilo arquitetural MVC : Model, View e Controller.
2.3 Silverlight 4
Silverlight é uma plataforma de desenvolvimento para a criação de aplicações ricas
(RIA) que simulam o modelo de interação do usuário das aplicações desktop, permitindo
recursos como arrastar e soltar, duplo clique, menu contextual, etc. O Silverlight foi a
resposta da Microsoft ao Adobe Flex e posteriormente ao Adobe Air.
Um aplicativo Silverlight é executado no dispositivo cliente através de um plug-in
(runtime ) gratuito previamente instalado. O plugin é compatível com os principais na-
vegadores do mercado mas apenas disponível para Windows. Em sistemas operacionais
4

8. Unix, como
MacOS e Linux, é possível executar aplicativos Silverlight graças ao projeto
1
Moonlight .
Além da questão da interação rica proporcionada, o Silverlight destina-se, principal-
mente, a:
• Criação de animações complexas.
• Streaming de vídeos.
• Exibição de um conjunto de imagens com altíssima resolução, utilizando-se do com-
ponente Deep Zoom, por exemplo.
Com o lançamento do Windows Phone 7 o Silverlight, que estava perdendo o interesse
dos desenvolvedores por conta de novos padrões Web como HTML5 e CSS3, voltou a
receber um pouco mais de atenção por parte da comunidade de desenvolvimento.
O estilo arquitetural recomendado é o Model-View-View Model (MVVM ). Esse estilo
surgiu da necessidade de se separar as responsabilidades dentro da camada cliente. O
MVVM é baseado no Presentation Model, de Martin Fowler. O objetivo é separar to-
talmente Model e View, de maneira que a ViewModel serve como colaentre os dois.
Aplicando elmente o MVVM é possível criar Composite Applications, aplicaçoes que
compartilham o mesmo Model e/ou ViewModel, por exemplo: Uma aplicação Mobile
usando Silverlight e uma aplicação desktop usando o WPF. Isso permite um ganho de
produtividade em cenários multiplataforma e consequentemente diminuição do tempo de
desevolvimento e custos. Dentre as principais vantagens desse padrão estão:
• Permite que tanto a equipe de desenvolvimento quanto a equipe de design gráco
trabalhem de forma independente umas das outras.
• Permite a reutilização de toda a lógica da camada de apresentação caso seja necessá-
rio portá-lo para Windows Presentation Foundation (WPF ) e/ou Windows Phone
7 (WP7 ).
• Aumenta a testabilidade da aplicação, pois o domínio está desacoplado da lógica de
visualização, geralmente como um serviço
É importante ressaltar que, em cenários de uso RIA, toda a lógica do negócio é trans-
ferida para o servidor e toda a lógica de apresentação é transferida para o cliente.
3 Visão Geral dos Padrões Envolvidos
3.1 WCAG
Atualmente em sua segunda versão, a Web Content Accessibility Guidelines (WCAG ),
é um conjunto de 12 recomendações criadas pelo World Wide Web Consortium (W3C ).
Essas recomendações podem ser organizadas em 4 princípios:
• Perceptível;
1 http://www.mono-project.com/Moonlight
5

9. • Operável;
• Entendível;
• Robusta;
Para cada recomendação existem três níveis de conformidade:
• A;
• AA;
• AAA;
O objetivo da WCAG é prover explicações de como tornar o conteúdo da Web aces-
sível para pessoas com algum tipo de deciência. Nesse contexto, o conteúdo da Web
pode compreender a informação ou a aplicação na Web, incluindo textos, imagens, sons,
formulários e etc.
4 Integração
Para a construção dessa prova de conceito foram utilizadas as tecnologias presentes
na Tabela 1.
Funcionalidade Tecnologia
Injeção de dependência Unity Application Block
Persistência dos dados NHibernate + FluentNHibernate + SQLite
Exposição de serviços Windows Communication Foundation
Interface ASP.NET MVC 3
Captcha Silverlight 4
Servidor Web Casini (Servidor Web interno do Visual Studio )
Mapeamento de objetos Automapper
Tabela 1: Tabela contento as funcionalidades e tecnologias utilizadas.
4.1 Ambiente de desenvolvimento
Inicialmente foi colocada em questão a possibilidade de se utilizar um ambiente livre
para o desenvolvimento da prova de conceito. Realizamos o download de uma máquina
virtual disponibilizada pelo projeto Mono 2 . Essa máquina virtual possui o sistema ope-
racional OpenSuse e todo o conjunto de aplicativos criados pelo projeto Mono.
Conseguimos sem muitos problemas executar vários exemplos utilizando o ASP.NET
MVC 2, mas nos deparamos com os seguintes problemas:
• Descobrimos que ainda não há suporte completo para WCF.
2 http://www.mono-project.com
6

10. • Por questões de licensiamento, não é possível executar completamente o ASP.NET
MVC 3, uma vez que apenas a Microsoft pode redistribuir os assemblies do Razor,
um engine mais uente para o ASP.NET MVC.
• Apesar do do Moonlight (implementação livre do Silverlight ) funcionar
runtime
bem, o SDK ainda não possui todas as opções e facilidades disponíveis na versão 4
do Silverlight.
Optamos então por criar uma máquina virtual executando o Windows XP como sis-
tema operacional e utilizamos o Visual Studio 2010 como nossa IDE. O Visual Studio 2010
é um pré-requisito caso se deseje trabalhar utilizando o .NET Framework 4.0, ASP.NET
MVC 3 e Silverlight 4. Por questões comerciais, a Microsoft não provê suporte ao de-
senvolvimento de novos aplicativos com essas tecnologias nas versão anteriores do Visual
Studio.
A única alternativa provável no ambiente Windows ao Visual Studio seriam as fer-
ramentas Express disponibilizadas gratuitamente pela Microsoft. Entretanto, essas fer-
ramentas não possuem integração entre si, tornando o desenvolvimento mais lento, bem
como nao podem ser utilizadas para a criação de software comercial. Ferramentas como
o Scaolding do ASP.NET MVC 3 estão disponíveis apenas para o Visual Studio 2010,
por exemplo.
Criamos pastas dentro da estrutura do projeto no Visual Studio para separar os di-
versos conceitos envolvidos no nosso projeto.
4.2 Estrutura do Projeto - Domínio
A primeira pasta que criamos foi chamada domínio e representa todo o código relaci-
onado ao negócio da Gonzo University. O código presente nessa camada é independente
da camada de apresentação. Dentro dessa pasta existem 3 projetos:
Figura 3: Visão geral da camada de domínio.
• Entity :
Contêm todas as entidades relacionadas ao negócio. Em uma futura imple-
mentação, conterá todas as regras relacionadas a cada entidade do domínio.
• Repository :Contêm o mapeamento do FluentNHibernate, uma facilidade que poupa
o desenvolvedor da criação de um gigantesco arquivo de conguração, assim como
cria o esquema do banco de dados, caso o mesmo não exista. Contêm as classes
reponsáveis por realizar a persistência das entidades.
7

11. • Service :
É basicamente uma fachada para o mundo. Em uma implementação futura,
trabalhará apenas com Transfer Objects. Hoje, para diminuir a complexidade da
implementação, trabalha diretamente com as entidades.
4.2.1 Entity
No cenário implementado, todas as classes desse projeto são apenas POCOs. Em
um cenário que exigisse uma implementação com regra de negócio, as mesmas estariam
contidas dentro das entidades
4.2.2 Repository
No projeto Repository utilizamos dois projetos opensource para realizar a persistência
das entidades: NHibernate e FluentNHibernate.
NHibernate é um framework objeto-relacional portado da plataforma Java e o mais
estável hoje no .NET Framework. É um framework extremamente exível e que não está
atrelado a nenhuma implementação especíca de SGBD, ao contrário de alguns outros
frameworks como LINQ to SQL, por exemplo.
FluentNHibernate é um framework que facilita a conguração do NHibernate através
de uma linguagem especíca de domínio (DSL). Essa linguagem diminui em muito o tempo
gasto para conguração inicial e facilita a evolução/manutenção.
Figura 4: Diagrama representando o projeto Repository.
4.2.3 Service
É o responsável por expor uma fachada para manipulação do domínio. Em nossa im-
plementação o serviço expõe as próprias entidades por não haverem regras implementadas
dentro das mesmas. Em um cenário que houvesse regras, o ideal seria trafegar Transfer
Objects entre a camada de Service e qualquer requisitante.
8

12. Figura 5: Implementação atual trafegando objetos da camada Entity.
Figura 6: Implementação futura trafegando apenas Transfer Objects.
4.3 Estrutura do Projeto - Infra-Estrutura
A segunda pasta que criamos foi para infra-estrutura:
Essa camada é responsável por requisitos ortogonais no sistema como segurança, lo-
calização, etc. Temos basicamente dois projetos:
• Captcha : projeto que cria toda a infra-estrutura para nosso Captcha implementado
em Silverlight.
• Location : projeto mock para substituir o webservice dos Correios.
4.3.1 Captcha
Criamos esse projeto para prover toda a infra-estrutura para nosso Captcha. Como
precisávamos demonstrar a tecnologia Silverlight, optamos por fazer a implementação do
Captcha nessa tecnologia.
Entretanto, por ser um código que é executado na dispositivo cliente, ele possui uma
série de restrições em relação aos namespaces e operações que podem ser executadas.
9

13. Figura 7: Visão geral da camada de infra-estrutura.
Nessa camada referenciamos o namespace System.Drawings e Microsoft.Speech. O na-
mespace System.Drawings foi utilizado para gerar uma imagem baseada em uma palavra
randomicamente gerada e o namespace Microsoft.Speech, respon±avel por sintetizar o som
dessa palavra. Ambos, imagem e som, são serializados e trafegados pela rede utilizando
um array de bytes.
4.3.2 Location
Criamos esse projeto para servir como uma API de localização, uma vez que não seria
possível utilizar o webservice dos Correios durante a apresentação da prova de conceito.
4.3.3 InfraService
É o responsável por expor uma fachada para as APIs de infra-estrutura.
4.4 Estrutura do Projeto - Web
A última pasta é o projeto Web especicamente. Essa pasta contêm dois projetos:
• Controle Silverlight do Captcha
• Projeto WEB ASP.NET MVC 3
4.4.1 Captcha
O projeto Captcha simplesmente dene a interface do Captcha e invoca o serviço de
Segurança para obter os dados necessários para seu correto funcionamento. Pelo fato de
Silverlight não prover suporte a reprodução de arquivos WAV, foi necessário inserir código
de terceiros para a decodicação.
O componente é responsável então por exibir uma imagem na tela e pedir ao usuário
que digite quais são os caracteres que aparecem na imagem. Caso o usuário não seja capaz
de identicar os caracteres, ele ainda é capaz de ouvir cada caracter ser soletrado.
10

14. Ao realizar a validação, o controle Silverlight invoca uma função Javascript na página
informando se o valor preenchido no captcha é válido ou não.
Figura 8: Visão geral do componente Captcha.
4.5 Projeto Web
O projeto web é composto basicamente pelos seguintes componentes:
Figura 9: Visão geral da camada Web.
• Controller: recebe requisições HTTP e responde com as views apropriadas. É o
responsável pelo modelo de navegação na apresentação. É o responsável para fazer
ponte entre um Model e o Service.
11

15. • Model: responsável por conter os dados que devem ser representado na interface.
• View: responsável por determinar como os dados serão renderizados e responsável
por interagir com o controller enviando e recebendo informações do mesmo.
• Front-Controller (Global.asax): Responsável por rotear todas as mensagens dentro
da aplicação. Responsável por congurar o container de injeção de dependências.
Responsável pelo modelo de URL's.
• AutoMapper:Responsável por fazer mapeamento automático entre dois tipos, por
exemplo, mapear as informações presente no StudentModel (Model) para Student
(Entity) e vice-versa.
• Unity: Framework responsável por fazer a injeção de dependências dentro do pro-
jeto. Posteriores requisitos ortogonais: log, segurança, podem ser endereçados
utilizando-o.
• Action Filters: Alternativa ao Unity nativa do próprio ASP.NET MVC 3.
4.5.1 Model
No caso do projeto Web, para cada entidade foi criado um objeto no Model, que
reete dedignamente as propriedades da entidade. Essa decisão foi tomada pois, o Model
está diretamente atrelado a interface, recebendo metadados que o tornam dependente
do framework ASP.NET MVC. Um outro problema é o fato de que utilizamos Views
fortemente tipadas, o que diculta o trabalho de exibição de informações que não estão
presentes na entidade, como por exemplo a lista de todos os cursos disponíveis.
4.5.2 Controller
Foram implementados dois controladores, StudentController e CourseController. Para
cada controller foram geradas página de listagem de edição, de criação, de detalhe e de
exclusão. As views foram implementadas utilizando o framework Razor e são fortemente
tipadas com o modelo.
Uma vez que criamos todos os objetos do Model, iniciamos a implementação dos Con-
trollers. O ASP.NET MVC 3 mantêm uma convenção sobre conguração que torna a
criação de toda a estrutura da aplicação muito mais simples.
Os Controllers também caram responsáveis por executar a ponte entre o domínio e
nosso Model. Eles são responsáveis por invocar as operações correspondentes no serviço e
em seguida, realizar o mapeamento das entidades para o Model correspondente utilizando
o AutoMapper.
4.5.3 View
Uma vez criadas todas as operações de que necessitariamos no Controller (Index,
Details, Create, Save, Delete )
pudemos utilizar a ferramenta de Scaolding para gerar
todas as Views fortemente tipadas com base nos objetos do nosso Model.
12

16. 5 Vantagens e desvantages
5.1 Vantagens e desvantagens do .NET Framework 4
5.1.1 Vantagens
• Oferece melhorias no tempo de inicialização, tamanhos de trabalho conjunto, e um
desempenho mais rápido para aplicações multithread.
• Introduz um novo modelo de programação para escrever código multithread e as-
síncrono, que simplica o trabalho dos desenvolvedores de aplicativos e bibliotecas.
• Fornece simplicações, melhorias e capacidades expandidas no modelo de segurança.
• Várias interfaces genéricas e delegates agora suportam covariância e contravariância.
• Fornece a capacidade de monitorar o desempenho de seus domínios de aplicação.
5.1.2 Desvantagens
• Potencial quebra de compatibilidade com códigos legados construídos sobre versões
anteriores. Isso ocorreu apenas entre a versão 1.1 e 2.0, onde ocorreram grandes
mudanças, inclusive nas instruções da IL (Intermediate Language )
• Dependência de um único fornecedor. Apesar de hoje a Novell suportar o projeto
Mono, com a recente aquisição da Novell pela Attachament, o futuro do Mono
passou a ser incerto.
5.2 Vantagens e desvantagens do ASP.NET MVC 3
5.2.1 Vantagens
• Aumento do controle sobre o HTML gerado.
• Torna mais simples gerenciar a complexidade da solução, dividindo a aplicação em
unidades de única responsabilidade.
• Não utiliza ViewState ou formulários baseados no servidor. Isso torna o ASP.NET
MVC ideal para desenvolvedores que buscam maior controle sobre o comportamento
da aplicação.
• Utiliza o padrão Front Controller para processar as requisições a aplicação Web
através de um único controlador. Isso permite uma infraestrutura de roteamento
rico, por exemplo, com URLs amigáveis complexas.
• Facilita a adoção do desenvolvimento dirigido por testes (TDD).
• Facilita a separação das responsabilidades do time de desenvolvimento, por exemplo,
desenvolvedores e web designers, minimizando a interferência de um sobre o trabalho
do outro.
13

17. • Como o modelo MVC gerencia múltiplos visualizadores usando o mesmo modelo é
fácil manter , testar e atualizar sistemas múltiplos;
• É muito simples incluir novos clientes apenas incluindo seus visualizadores e con-
troles;
• É possível ter desenvolvimento em paralelo para o modelo , visualizador e controle
pois são independentes;
• É mais fácil gerenciar a complexidade da aplicação dividindo-a em modelo, visuali-
zador e controlador (MVC);
5.2.2 Desvantagens
• Curva de aprendizado maior. A tecnologia Web Forms acompanha o ASP.NET
desde sua primeira versão ao passo que o framework MVC está em sua terceira
versão, a primeira robusta o suciente para utilização em ambientes corporativos
complexos.
• Necessita maior conhecimento de HTML, CSS e JavaScript, ainda que exista ma-
neiras mais fáceis de usar AJAX, por exemplo.
• Não é aconselhável para pequenas aplicações.
• Requer uma quantidade maior de tempo para analisar e modelar o sistema;
• Requer pessoal com conhecimento especializado;
• Não é aconselhável para pequenas aplicações;
5.3 Vantagens e desvantagens do Silverlight
5.3.1 Vantagens
• Aplicações multibrowser;
• Linguagem XML para denir a interface, assim como no WPF;
• Maior capacidade para lidar com conteúdo multimídia, principalmente vídeo;
• Suporte à todas as linguagens oferecidas pelo .NET Framework, inclusive linguagens
dinâmicas como IronPython e IronRuby (DLR - Dynamic Language Runtime)
5.3.2 Desvantagens
• Suporte limitado para imagens: suporte apenas para PNG e JPG;
• O Silverlight não possui qualquer API nativa de controle de áudio, nem mesmo para
o playback de arquivos WAV;
• A versão para sistemas não-Windows ainda é limitada ao equivalente à versão 2.0
do Silverlight
14

18. 5.4 Vantagens e desvantagens do WCAG
5.4.1 Vantagens
• Facilidade de uso da aplicação;
• Conformidade com leis governamentais, por exemplo, os padrões e-Gov de Acessi-
bilidade no Brasil;
• Oferece uma qualicação global de acessibilidade.
5.4.2 Desvantagens
• Requer mais tempo para desenvolvimento.
• Necessidade de equipe qualicada.
• Maior investimento.
6 Principais cenários de uso
6.1 ASP.NET MVC 3
• Aplicações web complexas onde gerenciar a complexidade da aplicação é um risco
considerável e manutenibilidade e testabilidade são características mitigadoras.
• Novos projetos Web que não possuem legados técnicos onde é possível escolher um
framework que incentiva a aplicação de boas práticas de programação
• Design baseado em estilos arquiteturais conhecidos.
6.2 Silverlight
• Aplicações Ricas para Internet ou aplicações desktop conectadas a web (RIA)
• Aplicações com uso intensivo de conteúdo multimídia (áudio e vídeo)
• Aplicações para dispositivos móveis (Windows Phone 7)
7 Estilos Arquiteturais
A arquitetura de um sistema pode aderir a um ou mais estilos arquiteturais. Um
estilo dene os tipos de elementos que podem aparecer em uma arquitetura e as regras
que regem a sua interconexão.
Esses estilos podem simplicar o problema de denição de arquiteturas de sistema. A
maioria dos sistemas de grande porte aderem a vários estilos.
A seguir listamos os estilos arquiteturais que podem ser empregados ao utilizar ASP.NET
MVC 3 e/ou Silverlight e uma breve descrição de cada estilo:
15

19. Figura 10: Visão geral do estilo arquitetural MVVM.
7.1 Client / Server
Segrega o sistema em duas aplicações, onde o cliente faz uma requisição de serviço ao
servidor.
7.2 Arquitetura baseada em componentes
Decompõe o design da aplicação em componentes lógicos e funcionais que são inde-
pendentes de local e expõe interfaces de comunicação bem denidas.
7.3 Arquitetura em camadas
Separa as responsabilidades da aplicação em grupos bem denidos (camadas).
7.4 N-Tier / 3-Tier
Separa funcionalidade em segmentos de forma muito similar ao estilo de camadas,
mas com cada segmento sendo uma camada localizado sicamente em um computador
separado.
7.5 Orientado a Objetos
Um estilo arquitetural baseado na divisão de tarefas para uma aplicação ou sistema
em reutilização individual e objetos auto-sucientes, cada um contendo os dados e com-
portamentos relevantes ao objeto.
16

20. 7.6 Apresentação Separada
Separa a lógica para gerenciar a interação do usuário da visualização da interface de
usuário (UI) e dos dados com os quais o usuário trabalha.
8 Casos de uso reais no Brasil
8.1 ASP.NET MVC 3
• E-commerce - TRIP Linhas Aéreas
8.2 Silverlight
• Sistema para gestão de publicidade em Aeroportos (Infraero)
• Sistema de apoio à scalização das obras municipais para a Copa do Mundo de 2014
(Tribunal de Contas do Estado de Minas Gerais)
• CreditCard (State Trust Bank)
9 Depoimento de usuários real da tecnologia
9.1 Entrevistado 1
P: Qual a tecnologia utilizada?
R: Silverlight e .NET Framework 4
P: A Equipe tinha conhecimento da tecnologia?
R: Não
P: Como e por que a tecnologia foi escolhida?
R: Pré-requisito do cliente
P: Qual a sua opinião sobre a adoção da tecnologia?
R: No projeto em questão foi bem empregada, pois, o cliente desejava uma riqueza na
interface que seria muito difícil de se fazer com outra tecnologia.
P: Quais os pontos positivos que você destacaria?
R: Baixa curva de aprendizagem, desenvolvimento de interfaces ricas com pouco tra-
balho, suporte visual para desenvolvimento das interfaces (Expression Blend).
P: E os pontos negativos?
R: Poucos componentes disponíveis, e os que existem, baixo poder de customização.
P: Você considera que a adoção da tecnologia inuenciou no sucesso do
projeto?
R: O projeto ainda não foi nalizado
P: Você voltaria a utilizar a tecnologia em outros projetos? Quais?
R: Sim, é muito bom desenvolver interfaces sem utilizar o HTML prostituidoou
ASP.NET. Em projetos que requerem interfaces ricas.
17

21. 9.2 Entrevistado 2
P: Qual a tecnologia utilizada?
R: ASP.NET MVC 3 e .NET Framework 4
P: A Equipe tinha conhecimento da tecnologia?
R: Não
P: Como e por que a tecnologia foi escolhida?
R: Como íamos trabalhar com serviços de terceiros, os arquitetos do projeto escolheram
MVC 3 pelo modo ágil de desenvolvimento porém não se preocuparam em dar treinamentos
para equipe.
P: Qual a sua opinião sobre a adoção da tecnologia?
R: Foi uma adoção precipitada pois pouca gente da equipe tinha experiência em uma
das tecnologias.
P: Quais os pontos positivos que você destacaria?
R: Não tenho experiência em MVC3 para equipes com mais experiência vários pontos
positivos poderão ser citados por exemplo a separação da camada de apresentação com a
de processamento.
P: E os pontos negativos?
R: Nada a declarar
P: Você considera que a adoção da tecnologia inuenciou no sucesso do
projeto?
R: O projeto não teve continuidade com MVC 3 pela pouca experiência dos partici-
pantes.
P: Você voltaria a utilizar a tecnologia em outros projetos? Quais?
R: Quando tiver um conhecimento maior voltarei a utilizar com certeza em projetos
web maiores pelas vantagens que se tem quanto na separação da Apresentação e do Modelo.
18

22. Referências
Microsoft (2009). Microsof Application. Architecture Guide: Patterns Practices.
Microsoft (2011a). Asp.net mvc 3. [Online; accessed 1-May-2011].
Microsoft (2011b). Microsoft silverlight. [Online; accessed 1-May-2011].
Microsoft (2011c). .net framework conceptual overview. [Online; accessed 1-May-2011].
19