Compilando aplicações ASP.NET 2.0 - Mudanças no Modelo de Código e Compilação

Tecnologias:

· C#

· VB.NET

· ASP.NET 2.0

MSDN Library:

http://msdn2.microsoft.com/en-us/library/ms228015.aspx

http://msdn2.microsoft.com/en-us/library/ms227972.aspx

http://msdn2.microsoft.com/en-us/library/ms247286.aspx

http://msdn2.microsoft.com/en-us/library/ms227976.aspx

Introdução

São muitas as novidades apresentadas no ASP.NET 2.0. Ganhamos produtividade numa escala jamais experimentada por desenvolvedores Web. Dentre as questões mais comuns que recebo, a compilação de aplicações ASP.NET é a mais freqüente. Por trás desta questão encontra-se uma das mudanças mais evidentes – o modelo de código do ASP.NET 2.0. Este artigo tem o propósito de esclarecer este assunto para que o desenvolvedor entenda essas mudanças e seu impacto sobre o processo de desenvolvimento.

Modelo de Código no ASP.NET 1.1

No ASP.NET 1.1, os desenvolvedores tinham duas opções básicas para codificar um WebForm. A primeira delas seguia o modelo tradicional do antigo ASP, permitindo escrever código diretamente no arquivo ASPX. Este processo é conhecido como Code-InLine. Funciona bem para comandos simples, mas para códigos mais complexos este modelo não é recomendado, entre outros fatores, a leitura de um arquivo ASPX com este modelo de código torna-se mais difícil porque o arquivo armazena um mix de código HTML para a camada de apresentação e código da sua linguagem para implementar a funcionalidade da página.

O modelo code-inline ficou ultrapassado com a chegada do ASP.NET. As regras de negócio e os gerenciadores de enventos podiam ser escritos num arquivo separado contendo apenas código. Este arquivo ficou conhecido como code-behind. Este novo modelo criava um link entre o arquivo ASPX (apresentação) e o arquivo de código. Esta mudança representou um avanço significativo que se traduziu em maior produtividade para as equipes de desenvolvimento, pois os designers podiam trabalhar nos arquivos de apresentação enquanto os desenvolvedores trabalhavam nos arquivos de código.

Os problemas do code-behind

O novo modelo de código inserido pelo ASP.NET, apesar do ganho de produtividade, também apresentava dois pontos negativos. O primeiro deles está relacionado à complexidade da aplicação do conceito de herança. No ASP.NET 1.1, o desenvolvedor utilizava o Visual Studio para arrastar-e-soltar controles na página ASPX, o Visual Studio então se encarregava de adicionar o código necessário para o correto funcionamento desses controles no arquivo de código (code-behind). Se novos controles fossem adicionados à página, novo código também era inserido no arquivo de código, deste modo o conceito de herança ganhava maior complexidade, pois o arquivo ASPX na verdade determinava o conteúdo do arquivo de código.

O segundo ponto negativo refere-se ao modelo de compilação. No ASP.NET 1.1, todos os arquivos de código, e todas as classes adicionais da sua aplicação eram compiladas e encapsuladas num assembly armazenado na pasta /bin da sua aplicação. O processo de compilação sempre ocorria antes do deployment da solução. Por outro lado, os arquivos eram compilados novamente em runtime sempre que recebiam o primeiro request. O problema deste processo é que o arquivo ASPX podia ser modificado sem que o arquivo de código fosse atualizado e a aplicação re-compilada. Quando isso acontecia, a aplicação podia apresentar erros ou comportamentos inesperados.

Modelo de Código no ASP.NET 2.0

O ASP.NET 2.0 continua suportando os dois modelos de código, code-inline e code-behind. Com relação ao modelo code-inline, as alterações foram mínimas, exceto pela mudança no Visual Studio 2005 que passa a suportar o modelo de desenvolvimento single-file (arquivo único), ou seja, você pode implementar um WebForm com todas as funcionalidades utilizando apenas o arquivo ASPX, exatamente como você fazia no antigo ASP.

O modelo code-behind foi aprimorado para corrigir os pontos negativos do ASP.NET 1.1. No ASP.NET 2.0 o arquivo de código não é mais uma implementação completa da classe Page. O arquivo code-behind segue o novo modelo de Partial Class. As classes parciais contém todo código implementado pelo desenvolvedor e omite o código gerado automaticamente pelo Visual Studio. Quando uma página ASPX com o novo modelo de code-behind é chamada, o ASP.NET 2.0 combina o arquivo ASPX e a classe parcial numa única classe ao invés de duas classes separadas.

As classes parciais usam uma nova palavra-chave (Expands no Visual Basic, ou Partial no C#) para indicar que o código nesta classe deve ser mesclado com outra classe quando em modo runtime. De maneira semelhante o arquivo ASPX utiliza uma nova diretiva CompileWith para indicar o arquivo de código associado.

O modelo de herança foi simplificado porque o arquivo de código (code-behind) não precisa mais conter as definições dos controles da página ASPX. Desta forma, o arquivo de código pode acessar automaticamente qualquer controle na página sem a necessidade de todo o código declarativo que era exigido no ASP.NET 1.1. Isto é possível porque o Runtime do ASP.NET 2.0 insere automaticamente as declarações exigidas para os controles e eventos no arquivo compilado ao final do processo, desta forma o desenvolvedor não precisa preocupar-se com isso.

Com esse novo modelo, o arquivo de código e a página ASPX são mesclados e compilados numa única e completa classe em runtime eliminando a complexidade do processo de compilação. A sincronização entre o arquivo de código e o arquivo ASPX é automatica, mas ainda assim é possível que o código seja alterado no arquivo ASPX e não atualizado no arquivo de código, contudo o desenvolvedor poderá localizar o problema de forma muito mais rápida uma vez que o ASP.NET 2.0 gerará uma Exception muito mais detalhada.

Modelos de compilação no ASP.NET 2.0

O ASP.NET 2.0 suporta diferentes modelos de compilação para uma aplicação Web, apresentados abaixo:

Default: (ASP.NET 1.x)

Neste modelo de compilação, os arquivos de código são compilados num assembly e armazenados na pasta /bin da aplicação. As páginas ASPX são compiladas por demanda. Este modelo funciona bem para a maioria dos websites. Contudo, este processo de compilação torna a primeira requisição de qualquer página da aplicação mais lenta do que as requisições subsequentes.

Não existe nenhum procedimento manual para realizar a compilação default. O Runtime do ASP.NET 2.0 se encarregará de realizar a compilação quando receber a primeira requisição para a aplicação. Se alguma alteração for feita, no próximo request da página alterada, o Runtime do ASP.NET 2.0 determinará as dependências do arquivo alterado e realizará a compilação apenas para os arquivos envolvidos na alteração.

Vantagens:

· Simples, pois o Runtime do ASP.NET faz todo o trabalho para você.

· É a melhor opção para a fase de desenvolvimento da sua aplicação Web, pois evita as etapas necessárias para realizar pré-compilações.

Desvantagens:

· Pode causar lentidão significativa no primeiro request da aplicação.

· Exige que os arquivos de código sejam armazenados no servidor de produção.

· Expõe todo código-fonte e inteface para qualquer usuário com acesso ao diretório da aplicação no servidor.

In-Place Compilation (Pré-Compilação no Servidor de Produção)

Você pode usar a ferramenta ASP.NET Compilation Tool (Aspnet_compiler.exe), localizada na pasta C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727, para pré-compilar sua aplicação. O processo é semelhante ao que ocorre em tempo de execução. A ferramenta provoca vários requests para o website provocando a compilação do mesmo. Se você alterar uma página da sua aplicação você deverá repetir o processo de pré-compilação, caso contrário o Runtime do ASP.NET 2.0 terá que fazer a compilação em tempo de execução na próxima requisição do arquivo alterado.

Vantagens:

· Tmpo de resposta para o primeiro request da aplicação é reduzido.

· Não é necessário executar nenhum procedimento especial para o deployment após a compilação.

Desvantagens:

· Exige que os arquivos de código sejam armazenados no servidor de produção.

· Expõe todo código-fonte e inteface para qualquer usuário com acesso ao diretório da aplicação no servidor.

Você deve usar esse modelo quando houver necessidade de frequentes alterações nas páginas e/ou quando quiser reduzir o tempo de resposta do primeiro request, mas lembre-se que os arquivos de código estarão disponíveis para todos que tiverem acesso à pasta da aplicação.

Deployment Pre-Compilation

Este novo modelo inserido no ASP.NET 2.0 permite ao desenvolvedor fazer a compilação completa da sua solução antes de fazer o deployment. Com a compilação completa, todos os arquivos code-behind, páginas ASPX, HTML, recursos gráficos, são compilados em um ou mais assemblies, dependendo do tamanho da aplicação e da configuração da compilação. Os assemblies contém o Website completo, com exceção do arquivo Web.config. Este modelo de compilação oferece a melhor performance e segurança se comparado com os outros modelos, porém remove a capacidade de qualquer alteração no Website após feito o deployment. Se você está trabalhando num website altamente visado, ou que exige alto nível de segurança, este modelo é a melhor opção para o deployment final. Contudo, se você está desenvolvendo um pequeno website, trabalhando numa intranet local, e seu projeto requer frequentes mudanças, este modelo de compilação porde tornar-se inviável.

Pre-Compilation com camada de apresentação atualizável

Com a utilização do parâmetro –u da ferramenta ASP.NET Compilation, o desenvolvedor pode pré-compilar os arquivos de código (*.vb ou *.cs) e os arquivos de recursos (*.resource), deixando o código da camada de apresentação (HTML) disponível para atualizações. Depois de realizar o deployment do website no servidor de produção, os arquivos ASPX podem ser modificados sem a necessidade de recompilar a aplicação.

Vantagens:

· Tempo de resposta para o primeiro request da aplicação é reduzido.

· Os designers podem modificar a aparência do Website sem necessidade de recompilar a aplicação.

· A propriedade intelectual é protegida pois os arquivos de código ficam disponíveis neste modelo de compilação.

Desvantagens:

· Adiciona uma nova etapa no processo de deployment, pois a compilação precisa ser feita antes da publicação do website

· A propriedade intelectual contida na camada de apresentação (ASPX) continua disponível para todos os usuários que possuem acesso à pasta da aplicação.

Pre-Compilation com camada de apresentação não atualizável

A ferramenta ASP.NET Compilation pode compilar todo código-fonte de uma aplicação, incluindo os arquivos de interface (ASPX, ASCX), encapsulando-os em assemblies que são publicados na pasta /bin da aplicação.

Vantagens:

· Tempo de resposta para o primeiro request da aplicação é reduzido.

· A propriedade intelectual é completamente protegida pois todos os arquivos de código-fonte e arquivos de apresentação são compilados em *.dlls.

Desvantagens:

· Adiciona uma nova etapa no processo de deployment, pois a compilação precisa ser feita antes da publicação do website.

· Qualquer modificação na camada de apresentação exigirá que o Website inteiro seja recompilado.

A janela de diálogo Publish Web Site

Com a ferramenta ASP.NET Compiler, o desenvolvedor pode compilar sua aplicação em qualquer um dos modelos apresentados neste artigo. Contudo, esta ferramenta é executada no prompt de comando, para os desenvolvedores que preferem uma interface gráfica, o Visual Studio disponibiliza as mesmas funcionalidades através da janela de diálogo Publish Web Site, que pode ser invocada a partir do menu Build. Nesta janela, o desenvolvedor poderá executar os processos de pré-compilação e ainda publicar seu Website no servidor de produção. A Figura 1 mostra a janela de diálogo Publish Web Site.

Figura 1: A janela de diálogo Publish Web Site.

Conclusão

Este artigo apresentou os principais pontos envolvidos no processo de compilação de uma aplicação ASP.NET 2.0, as diferenças comparadas à versão anterior (ASP.NET 1.1) e o uso da ferramenta ASP.NET Compiler. O desenvolvedor poderá aprofundar-se neste assunto acessando os links do MSDN Library citados no cabeçalho deste artigo.

Desenvolvimento - ASP. NET

Leia também