Utilizando o ASP.NET MVC Framework com o Visual Web Developer 2008 Express

ASP.NET MVC Framework foi projetado para o .NET Framework 3.5, mas você não é obrigado a utilizar a versão comercial do Visual Studio 2008. Se você ficou com vontade de experimentar o novo framework mas não tem acesso ao Visual Studio 2008, poderá utilizá-lo com o Visual Web Developer 2008 Express, que é uma versão mais enxuta (e gratuita) do Visual Studio 2008.

É importante levar em consideração que o ASP.NET MVC Framework foi feito utilizando o modelo de projeto Web Application. Atualmente, o Visual Web Developer 2008 Express (VWD Express) não suporta este tipo de projeto (ele cria somente projetos do tipo Web Site). Portanto, se você simplesmente instalar o ASP.NET MVC Framework e tentar criar um projeto no VWD Express, não irá conseguir. Você tem duas alternativas: a primeira, é adaptar manualmente seu projeto do tipo Web Site para utilizar o ASP.NET MVC Framework, como é mostrado neste post. A outra maneira, mais rápida e prática, é utilizar um template para projetos MVC para o VWD Express, feito por um desenvolvedor independente e que pode ser baixado em seu site.

Vale lembrar que essas são soluções temporárias, já que o ASP.NET MVC Framework ainda se encontra em versão CTP e o suporte nativo ao VWD Express será adicionado, pela Microsoft, em versões futuras.

Desvendando o ASP.NET MVC Framework

O Linha de Código publicou um artigo que escrevi chamado "ASP.NET 3.5 Extensions: Desvendando o ASP.NET MVC Framework". Ao contrário do artigo anterior, no qual foram apresentados aspectos mais conceituais, pois na época o ASP.NET MVC Framework ainda não estava disponível publicamente, neste novo artigo a abordagem é prática.

É apresentado como funciona o mecanismo de mapeamento de URLs do MVC Framework (que não referencia mais páginas, mas sim, classes - os controllers), como implementar esses controllers e passar dados para as views, além de algumas alternativas para renderizá-las (inclusive, utilizando alguns extension methods do MVC Toolkit). Durante o artigo, é desenvolvido um exemplo simples de leitor de feeds RSS utilizando o ASP.NET MVC Framework. Esse leitor armazena os dados dos feeds em um arquivo XML (que é manipulado através de classes do model utilizando LINQ to XML) e consulta as últimas atualizações de maneira on-line. Você pode fazer o download do código-fonte do exemplo e analisar seu funcionamento.

Como o artigo foi escrito utilizando-se a versão CTP do ASP.NET MVC Framework, as informações apresentadas estão sujeitas a alterações até o lançamento da versão definitiva. Sugestões e críticas são sempre bem-vindas. Espero que gostem!

ExemploMvcApplication.zip (86,60 kb)

ASP.NET MVC Framework CTP disponível para download

A versão CTP do ASP.NET MVC Framework, sobre o qual comentei outro dia, foi lançada e já pode ser baixada. Ele faz parte de um pacote chamado ASP.NET 3.5 Extensions que, além do MVC Framework, contém outras novidades, como melhorias no ASP.NET AJAX, ADO.NET Entity Framework e Data Services e alguns controles para Silverlight (veja mais detalhes). É necessário ter o Visual Studio 2008 ou o Visual Web Developer 2008 Express.

Considerações iniciais sobre o ASP.NET MVC Framework

Antes de você continuar, gostaria de deixar claro que, enquanto este post é escrito, o acesso ao ASP.NET MVC Framework está restrito a um grupo muito pequeno de pessoas (do qual, infelizmente, não faço parte). Portanto, tudo o que você vai ler aqui é baseado em informações que começam a aparecer na Internet e, portanto, sujeito a correções e/ou alterações. Até por conta disso, não pretendo abordar o lado prático do ASP.NET MVC Framework, ficando isso para uma próxima oportunidade. Abordarei um lado mais conceitual, com minhas impressões sobre o que tenho lido até o momento.


Antes, um pouco de história

Ao invés de entrar diretamente no assunto, acho importante contextualizar como o desenvolvimento de aplicações web tem evoluído. Nos primórdios da Web, a única maneira de se ter uma página dinâmica (cujo conteúdo poderia variar de acordo com determinadas circunstâncias), era através do uso de CGI - Common Gateway Interface. O CGI nada mais é do que um programa que segue certos padrões para ser executado em um servidor web qualquer, recebendo dados de entrada e gerando um resultado. Os dados de entrada geralmente são passados a partir de campos do formulário de uma página para o servidor web, que por sua vez executa o programa CGI, que irá fazer o processamento necessário e devolver o resultado (geralmente, um arquivo HTML) para o servidor web, que o repassará para o browser. Desenvolver um CGI exige um conhecimento maior sobre o protocolo HTTP e HTML, pois itens como cabeçalhos de resposta da requisição, tratamento dos parâmetros de entrada e o resultado HTML são responsabilidades do CGI. Assim, percebe-se que o desenvolvedor trabalha em um ambiente de mais baixo nível.

Representação do funcionamento de uma aplicação CGI

Com o passar do tempo, alguns servidores web ganharam extensões que permitiam ter acesso a mais recursos dos mesmos. Por exemplo, o servidor web da Netscape passou a ter o NSAPI - Netscape Server Application Programming Interface, enquanto que o IIS, da Microsoft, ganhou o ISAPI - Internet Server Application Programming Interface. O objetivo dessas extensões era o mesmo do CGI, ou seja, permitir a execução de programas no servidor web. Entretanto, há algumas diferenças entre essas duas tecnologias. Enquanto que para cada programa CGI é criado um processo em memória separado do processo do servidor web, aplicações ISAPI rodam no mesmo processo, o que as tornam mais rápidas, já que não há a sobrecarga da comunicação entre os processos. Por outro lado, caso algum bug em uma aplicação ISAPI cause um crash, o processo do servidor web é afetado (e conseqüentemente, as demais aplicações dele), enquanto que no CGI o problema fica limitado ao processo do mesmo.

Representação do funcionamento de uma aplicação ISAPI

Desenvolver utilizando essas tecnologias não era tarefa das mais simples, pois exigia conhecimentos sobre como era o funcionamento em um nível mais baixo. Visando melhorar a produtividade e deixar a atenção do desenvolvedor voltada para o que realmente importava (solução de problemas de negócios), começaram a surgir plataformas de desenvolvimento mais amigáveis. A Microsoft lançou o ASP - Active Server Pages, através do qual era possível desenvolver aplicações para web através de uma linguagem de script, normalmente VBScript. É importante destacar que o ASP é uma extensão ISAPI instalada no servidor web e que fornece um ambiente de execução de aplicações de mais alto nível. Assim, quando o browser requisita uma página ASP, o servidor web redireciona o pedido para a extensão ISAPI do ASP, que interpreta os comandos VBScript e devolve o resultado para o servidor web, que o repassa para o browser. O ASP abstraiu muito da camada de mais baixo nível relativa ao protocolo HTTP, mas ainda assim era necessário ter conhecimentos mais especializados de HTML.


ASP.NET

Com o lançamento da plataforma .NET em 2002, a Microsoft fez alterações importantes na sua infra-estrutura para aplicações web. Assim, o ASP deu lugar ao ASP.NET. O ASP.NET, assim como o ASP, é implementado através de uma extensão ISAPI do IIS. Entretanto, a semelhança entre ambos pára por aqui. Para se desenvolver em ASP.NET, ao invés de se utilizar linguagens de script, utilizam-se linguagens mais robustas, como C# e VB.NET, com amplo suporte às classes do .NET Framework. Além disso, o código passa a ser compilado ao invés de interpretado. Também foi introduzido o conceito de code-behind, no qual o código do programa fica separado do código HTML da página. Por falar nela, a página não é mais uma simples página HTML, mas sim um WebForm, com um modelo próprio de execução e orientado a eventos. Outro conceito novo foi o PostBack, que fazia com que cada requisição de página fosse feita para ela mesma. Confesso que isso causou certa estranheza em mim, pois até então, os posts dos formulários HTML eram feitos para outras páginas. Este modelo de PostBack veio acompanhado de outros novos conceitos, como o ciclo de vida de uma página e o ViewState. Além disso, o ASP.NET foi capaz de manter os valores dos campos do WebForm automaticamente a cada post.

O modo de se desenvolver aplicações, com o ASP.NET, ficou parecido com o modo de se desenvolver aplicações desktop Windows. Não era mais necessário possuir grandes conhecimentos de HTML e tão pouco do protocolo HTTP. Esse modelo de desenvolvimento permitiu que antigos desenvolvedores de aplicações desktop conseguissem migrar para o mundo web de uma forma mais natural. O fato do ASP.NET abstrair esses aspectos pode ser encarado como um avanço ou um problema. Pode ser um avanço na medida em que você ganha produtividade e deixa de se preocupar com detalhes que não deveriam tomar muito tempo. Mas pode ser um problema no momento em que a pessoa acha que esse modelo é a solução para todos os problemas e não se interessa pelo que ocorre nos bastidores, não entendendo o real funcionamento do processo. Isso fica mais evidente em quem veio do mundo desktop e naqueles que aprenderam a desenvolver aplicações web diretamente com o ASP.NET. Nesses casos, o modelo de desenvolvimento do ASP.NET acaba funcionando como um limitador, pois as pessoas, sem um entendimento mais profundo de como uma aplicação web funciona (independentemente da tecnologia), acabam tendo dificuldades quando precisam utilizar recursos além dos básicos. Um sinal claro disso são as dúvidas freqüentes que aparecem nos fóruns de discussão sobre, por exemplo, o uso de javascript no ASP.NET. Apesar dos avanços que o ASP.NET trouxe, ainda existem operações que somente são possíveis de serem feitas através do uso de javascript, pois envolvem o lado cliente (browser). A falta de entendimento entre o que é executado no servidor e o que é executado no cliente acaba dificultando o desenvolvimento de recursos mais avançados para a aplicação. Assim, apesar do desenvolvedor que utiliza os WebForms do ASP.NET não precisar conhecer muito de HTML e HTTP, não quer dizer que isso pode ser totalmente esquecido e que ele não precisará utilizar esse conhecimento em algum momento.


MVC

Ao mesmo tempo que a Microsoft evoluía sua plataforma de desenvolvimento, começaram a surgir na Internet projetos open-source que visavam disponibilizar frameworks para facilitar e agilizar o desenvolvimento de aplicações web. Um dos frameworks que mais ganhou atenção nos últimos tempos foi o Ruby on Rails, que utiliza o padrão MVC e é escrito na linguagem Ruby. A comunidade .NET também teve sua implementação independente para o padrão MVC, através do MonoRail.

O MVC - Model-View-Controller -  é uma arquitetura que divide uma aplicação em três partes: 1) o Model, responsável pela manutenção do estado dos dados (por exemplo, armazenando os dados em um banco de dados); 2) o View, responsável pela interface com o usuário (não deve possuir nenhuma lógica de aplicação e nem de acesso a dados); 3) o Controller, que controla a lógica da aplicação, manipulando os dados do Model e escolhendo o View a ser utilizado. Essa arquitetura permite a clara separação dos papéis de cada componente, o que facilita a execução de testes unitários na aplicação, entre outros benefícios.


ASP.NET MVC Framework

Recentemente, a Microsoft anunciou que está trabalhando em uma implementação da arquitetura MVC para o ASP.NET, chamado de ASP.NET MVC Framework. Você pode estar se perguntando: "Mas o modelo WebForm do ASP.NET já não separa o código da página HTML através do code-behind?". Apesar do código ficar separado (o que facilita a organização e possibilita que um designer trabalhe com a interface gráfica enquanto o desenvolvedor cuida do código), essas duas partes estão um tanto acopladas. É como se o Controller (code-behind) e o View (.ASPX) estivessem unidos. Isso dificulta, por exemplo, os testes unitários de sua aplicação, pois não é possível fazer os mesmos sem a execução da página.

Este novo modelo de desenvolvimento de aplicações ASP.NET traz algumas diferenças em relação ao modelo de WebForms usado até então. A primeira das diferenças é que as requisições de uma aplicação ASP.NET não serão mais feitas a uma página, mas sim a um Controller, que nada mais é do que uma classe .NET. Na prática, isso significa que não mais referenciaremos uma página ASPX em uma URL. Por exemplo, uma URL para exibir uma lista de produtos que no padrão WebForms seria assim:

http://www.site.com/produtos.aspx

Utilizando a arquitetura MVC ficará assim:

http://www.site.com/produtos

Isso também serve para os posts executados pelos formulários HTML. Assim, outra grande diferença em relação ao modelo WebForms é que o PostBack não mais existirá no MVC Framework. Isso mesmo, nada de fazer posts para a mesma página. Se pensarmos bem, veremos que faz todo sentido, já que a responsabilidade de decidir o que fazer com a requisição é do Controller, e a página ASPX servirá somente como um template para renderizar a resposta. Uma conseqüência da eliminação do PostBack será também a eliminação do Viewstate, o que para muitos é muito bem-vindo, já que ele deixa a página mais pesada, além de poder causar alguns outros problemas.

Outro aspecto que sofrerá alterações será em relação ao uso do ASP.NET AJAX, mais especificamente o UpdatePanel, pois o mesmo se baseia no controle <form runat="server">, que não existirá neste novo modelo. Entretanto, ainda não foi divulgado exatamente como trabalhar com AJAX no framework MVC.

Pelo que tenho lido e entendido, o desenvolvedor terá um controle maior sobre o HTML gerado, o que implica em trabalhar em um nível mais próximo do HTML/HTTP do que o exigido no modelo WebForms do ASP.NET. Assim, aqueles que entendem como uma aplicação web funciona e que consideram o modelo de WebForms muito complexo ou sofisticado, provavelmente optarão pelo framework. Já aqueles que sabem somente os aspectos básicos do funcionamento dos WebForms, provavelmente terão mais dificuldade ou até mesmo não verão motivos para utilizar o novo modelo.


Serei obrigado a usar o novo modelo do ASP.NET MVC Framework?

Não, o modelo WebForms do ASP.NET continuará existindo e evoluindo. O ASP.NET MVC Framework será opcional, ou seja, uma alternativa a ser considerada na escolha da melhor arquitetura da sua aplicação, mas não será imposta. Além disso, também será possível utilizar os dois modelos ao mesmo tempo (WebForms e MVC) em uma mesma aplicação.


Com qual versão do .NET Framework e do Visual Studio será possível usar o ASP.NET MVC Framework?

Será possível utilizá-lo a partir do .NET Framework 3.5 e Visual Studio 2008, inclusive na versão Express.


A previsão é que a primeira versão CTP - Community Technology Preview do ASP.NET MVC Framework esteja disponível para download na primeira semana de dezembro. Se você estiver interessado no assunto, sugiro estudar o material de referência abaixo.

Referências

 

Descobrindo quando o usuário sai de uma aplicação ASP.NET

Às vezes nos deparamos com a necessidade de realizar algum processamento ou executar algum código quando o usuário deixa uma aplicação web. Isso acontece nas seguintes situações:

  • o usuário deixa de utilizar a aplicação por um determinado período de tempo
  • o usuário acessa um outro site, deixando o site da nossa aplicação
  • o usuário fecha o browser

Escrevi uma série de artigos que mostra como podemos detectar a ocorrência das situações descritas acima. Para isso, mostro algumas técnicas, como o uso do evento Session_End do ASP.NET e o evento onunload do JavaScript em conjunto com requisições AJAX:

Descobrindo quando o usuário sai de uma aplicação ASP.NET - Parte 1

Descobrindo quando o usuário sai de uma aplicação ASP.NET - Parte 2

Descobrindo quando o usuário sai de uma aplicação ASP.NET - Parte 3

Aproveito para comunicar que, a partir destes, pretendo publicar os próximos artigos no site da comunidade ASPNETI.

Comentários, críticas e sugestões são sempre bem-vindos!

Lançado ASP.NET AJAX 1.0

A Microsoft lançou a versão final do ASP.NET AJAX, conhecido anteriormente pelo codinome Atlas, que é o framework para técnicas AJAX em .NET.

O legal é que o código-fonte da implementação do ASP.NET AJAX também foi disponibilizado para download.

Por fim, mas não menos importante, temos a participação direta de um brasileiro no ASP.NET AJAX Control Toolkit, que é um conjunto de controles já prontos que utilizam técnicas AJAX. Trata-se do MVP Fernando Cerqueira, que participou no desenvolvimento do toolkit. Parabéns!

Webcasts sobre segurança com AJAX

Para os desenvolvedores web preocupados com segurança (todos deveriam estar preocupados), começará esta semana uma série de webcasts sobre aspectos de segurança na utilização de AJAX, com ênfase maior no ASP.NET AJAX, conhecido anteriormente como Atlas.

Apesar de toda a badalação em torno dessa "nova" técnica, poucos têm se preocupado com as novas brechas que esse tipo de desenvolvimento pode introduzir, caso não sejam tomados alguns cuidados. Sugiro a inscrição.

Presente de Natal: material de estudo grátis

A Microsoft disponibilizou capítulos de alguns livros para download. Entre os temas, encontram-se ASP.NET AJAX e segurança em desenvolvimento de aplicações ASP.NET. Além disso, também é possível se inscrever, gratuitamente, em alguns cursos de E-Learning, como ASP.NET AJAX e ADO.NET 2.0.

Para completar, o MSDN Brasil lançou a segunda fase do programa Net Proctetor, que visa difundir o aprendizado de segurança no desenvolvimento de software. A Academia Net Protector funcionará como o programa Desenvolvedor 5 Estrelas mas, ao invés de acumular estrelas, serão acumulados escudos, até no máximo 4, que indicam o nível de conhecimento adquirido. O material também está disponível para download.

Aplicações web ricas e interativas somente com AJAX? Reveja seus conceitos com o WPF/E

Se você acha que uma melhor experiência do usuário e interatividade em aplicações ASP.NET, ou uma aplicação web qualquer, só são plenamente atingidas com o uso de técnicas AJAX, então é porque você não conhece o WPF/E. Isso é até natural, já que o CTP - Community Technology Preview - acabou de ser lançado no dia 04/12 Laughing

O ASP.NET AJAX, que ainda nem teve sua versão final lançada - está no beta 1, foi só o começo e já adquire ares de coisa do passado. O WPF/E - sigla para Windows Presentation Foundation Everywhere - é o codinome da tecnologia Microsoft para o desenvolvimento de aplicações web ricas e interativas, através do uso de vetores gráficos, animações e outros recursos multimídia. Como seu nome indica, ele é um subconjunto do WPF, tecnologia responsável pela parte de User Interface - UI - no .NET 3.0/Windows Vista, e utiliza o XAML (eXtensible Application Markup Language) como linguagem de definição de interface (uma espécie de HTML turbinado).

Para utilizar uma aplicação que faz uso do WPF/E, é necessário instalar um plug-in (cujo tamanho é de aproximadamente 1 MB) para que o browser consiga interpretar o conteúdo XAML. Mas não pense que a utilização do WPF/E ficará restrita aos usuários do Windows ou do Internet Explorer. Já existe uma versão do plug-in para Macintosh, e também suporte aos browsers Firefox e Safari. Ainda não há uma versão do plug-in para Linux, mas levando-se em conta o anúncio do acordo entre Novell e Microsoft para promover a integração entre as duas plataformas, feito há algumas semanas, não será surpresa se ela for anunciada no futuro.

A notícia é boa também para os desenvolvedores, já que, através de HTML e JavaScript, será possível acessar e manipular o conteúdo WPF/E. Além disso, ele também se integrará totalmente com a arquitetura do ASP.NET (inclusive fazendo uso do ASP.NET AJAX, mas sendo possível a utilização de qualquer outro framework AJAX), reaproveitando os conhecimentos anteriormente adquiridos pelos desenvolvedores, além da integração com as ferramentas Visual Studio (e linguagens já conhecidas como C# e VB.NET) e, no caso dos designers, o Expression Studio, para a criação de código XAML.

Muitos já estão chamando o WPF/E de "Flash Killer", uma alusão ao fato de que essa nova tecnologia é um concorrente direto do Flash, da Macromedia/Adobe. A grande vantagem, a meu ver, é a integração com tecnologias já existentes, o que não obriga o desenvolvedor a aprender uma arquitetura ou linguagem totalmente nova, como acontece com o Flash. Seguem alguns links úteis para se aprofundar no assunto:

Announcing the release of the first "WPF/E" CTP

Getting Started with "WPF/E" (Code Name)

"WPF/E" (Code Name) Architecture Overview

"WPF/E" Downloads

"WPF/E" FAQ

Documentação e White Papers

ASP.NET AJAX Beta 1

O Atl...herrr... ASP.NET AJAX teve sua versão Beta 1 lançada pela Microsoft na última semana. Entre as várias novidades do Beta 1, as que mais chamaram minha atenção foram:

  • divisão de código javascript em arquivos, para que o browser faça o download somente do que realmente é necessário;
  • suporte total ao browser Safari;
  • melhorias no suporte a depuração (debug) de código javascript através do Visual Studio 2005, permitindo que sejam geradas duas versões de código javascript : uma em modo Debug e outra em modo Release (chamada de Retail), mais compacta e otimizada;

Para saber mais sobre as principais novidades, leia o anúncio.

Se você já vinha desenvolvendo aplicações utilizando alguma das versões CTP do Atlas (como era conhecido anteriormente o ASP.NET AJAX), então sugiro fortemente que leia os seguintes documentos:

Ricardo Oneda.