Presente de fim de ano

Aqui vão algumas dicas de conteúdo técnico gratuito, para quem estiver a fim de estudar:

Gostaria de aproveitar para desejar a todos que acompanham este blog um feliz Natal e um ótimo ano de 2008!

Conteúdo técnico da Microsoft em português

Não há como negar que a maior parte do conteúdo sobre tecnologia produzido atualmente é feito em inglês. Infelizmente, por diversos motivos, não são todas as pessoas que se sentem à vontade lendo nesse idioma, fazendo com que surjam barreiras na adoção e no uso correto de tecnologias. Já há algum tempo, a Microsoft vem lançando algumas iniciativas que visam fornecer conteúdo técnico localizado para o português do Brasil:

  • muitos artigos do MSDN americano podem ser encontrados traduzidos no MSDN Brasil
  • a revista MSDN Magazine também pode ser lida em português
  • a próxima versão do SQL Server, a 2008, será a primeira com interface traduzida para o português
  • desde o ano passado, está disponível a documentação do Visual Studio 2005 e .NET Framework 2.0 do MSDN em português, em formato wiki
  • recentemente, também foram lançadas as versões em português das documentações do SDK do Office SharePoint Server 2007 e do Windows SharePoint Services 3.0, também em formato wiki

Particularmente, acho o projeto do MSDN Wiki muito interessante. Como seria muito trabalhoso (e caro!) um grupo de pessoas traduzir o conteúdo, optou-se pela tradução automática via software. Imagino que a tradução de textos deve ser um dos maiores desafios da área, já que não basta termos dois dicionários, um em cada idioma, e procurar neles o correspondente de cada palavra. Apesar das línguas possuírem suas regras, as mesmas são flexíveis e possuem muitas nuances, que uma tradução literal não contempla. Além disso, o idioma sofre alterações diárias, não em suas regras, mas no seu uso. Considerando todos esses obstáculos, o nível de tradução obtido pelo MSDN Wiki é muito bom. Claro que alguns pequenos problemas existem, mas na maior parte das vezes, nem se percebe que a tradução foi feita automaticamente, de tão perfeito que é o resultado. O que eu acho mais legal no formato wiki é que, além de corrigir eventuais falhas de tradução, todos nós da comunidade podemos incluir conteúdo, como exemplos, dicas e informações, enriquecendo o material.

Se você não conhece os sites, sugiro visitá-los e contribuir para melhorá-los. E sempre que alguém reclamar sobre a falta de conteúdo em português, não deixe de indicar esses links.

Mais spam

Não é só o theSpoke que apresentou problemas ultimamente. Meu blog tem enfrentado alguns problemas técnicos nas últimas semanas, impossibilitando-me de postar e tornando-o inacessível em boa parte do tempo. Pelo que tenho analisado, minha conclusão até o momento é que isso foi provocado pela quantidade absurda de blog spam que tem sido gerado nos comentários. Para vocês terem uma idéia, em três meses foram aproximadamente 36.000 comentários classificados como spam. Você leu corretamente, são trinta e seis mil!

Apesar de possuir um filtro anti-spam, sobre o qual havia comentado há alguns meses, o mesmo não impede que o comentário seja gravado no banco de dados, mesmo identificando-o como sendo um spam. Assim, hoje implementei no blog um sistema de CAPTCHA, que são aquelas letras e números aleatórios que aparecem no momento de se escrever algum comentário. O objetivo é que isso consiga barrar os robôs que postam comentários, evitando que esse lixo seja gravado no banco de dados e consuma espaço desnecessário. Desculpem-me pelo transtorno que isso possa provocar.

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.

Tech-Ed Brasil 2007

Neste ano, infelizmente, não pude ir a todos os dias do Tech-Ed Brasil (mas já foi melhor que o ano passado, quando não estive presente em nenhum dia). Só pude comparecer na sexta-feira, dia 07 de dezembro, último dia do evento. A seguir, um breve resumo do que assisti:

Deep Dive no ASP.NET: nessa apresentação, Israel Aéce mostrou algumas funcionalidades mais avançadas que estão disponíveis desde o ASP.NET 2.0 e que quase não são abordadas em palestras do assunto (e que poucas pessoas conhecem). Destaque para o Client-Side Callbacks, páginas assíncronas (que apesar de não apresentar diferenças para o usuário final, pode melhorar a performance do lado servidor da aplicação), Control Adapters (que permitem customizar a renderização gerada pelos controles do ASP.NET, semelhante ao CSS Control Adapters), Virtual Path Providers (um mecanismo para armazenar os arquivos e conteúdo de uma aplicação ASP.NET em um repositório diferente do sistema de arquivos, como por exemplo, em um banco de dados) e Substitution Cache (define uma região dentro da área armazenada em cache que deve ser sempre atualizada).

Programando com Microsoft Windows Communication Foundation: não gostei muito desta palestra. Foram apresentados alguns conceitos básicos do WCF e SOA, e como desenvolver um serviço nessa plataforma. O problema é que muito código estava em slides e programação mesmo vimos pouca, apesar do título da palestra. Além disso, parece que essa apresentação era um tipo de segunda parte de uma outra palestra feita na quinta-feira, portanto, eu estava me sentindo um pouco perdido.

Silverlight - Por uma web mais rica: Cezar Guimarães nos deu uma pequena amostra do que já é possível fazer com o Silverlight 1.0 no desenvolvimento de Rich Internet Applications - RIA. Nessa versão, o foco está em multimídia e javascript, muito javascript. Agora as atenções passam a se voltar para a versão 2.0 (antigamente chamada de 1.1), que vai permitir a execução de código .NET no browser do usuário e está prevista para ser lançada em 2008.

ASP.NET AJAX - Otimizando e Estendendo: o objetivo de Fernando Cerqueira foi mostrar os cuidados que devem ser tomados quando desenvolvemos aplicações AJAX no ASP.NET. Não basta simplesmente colocar um UpdatePanel na página e jogar todos os controles dentro dele, afinal, mesmo usando AJAX, as requisições ao servidor continuam sendo feitas por "debaixo dos panos". Assim, o uso de vários UpdatePanels e, em um cenário mais avançado, restringir o tráfego somente aos dados utilizando o formato JSON pode contribuir significativamente para diminuir a quantidade de bytes trocada entre o servidor web e o browser. Para quem não conhece, a ferramenta utilizada para mostrar o que é trafegado entre o browser e o servidor web é o Web Development Helper.

Gostaria de ter assistido a outras paletras, como Internet Information Services 7 para Desenvolvedores e ADO.NET Entity Framework, mas como elas aconteceram na quinta-feira, não foi possível. De qualquer maneira, foi um bom evento, de grande porte, como tem acontecido com os últimos Tech-Eds, no qual, além de poder aprender um pouco mais, podemos reencontrar os amigos.

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