Revista MSDN Magazine Edição 28 - Visão geral dos novos serviços, controles e características

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

Artigo Originalmente Publicado na MSDN Magazine Edição 28

msdn28_capa.jpg

Clique aqui para ler todos os artigos desta edição

 

Visão geral dos novos serviços, controles e características


  Desde sua introdução em 2002, o ASP.NET tem se tornado um padrão para aplicações Web rodando em servidores Microsoft Windows. Na versão 2.0 do Microsoft .NET Framework, o ASP.NET surpreende pela quantidade de novidades. Seu objetivo é reduzir a quantidade de código necessário para realizar tarefas de programação comuns na Web em 70% ou mais. Esses novos serviços, controles e características fazem a versão 2.0 do ASP.NET ser tão significativa com relação à versão anterior, assim como o  ASP.NET 1.x foi para o ASP clássico. Neste artigo veremos uma ampla visão das novas características do ASP.NET 2.0, aprofundando-nos em áreas selecionadas e usando programas exemplo para ressaltar características chave. Os vários exemplos citados ao longo de todo este artigo são parte do AspNet2Samples, um aplicação de demonstração disponível para download no endereço deste artigo.

Codebehind 2.0

O ASP.NET 1.x suporta dois modelos de codificação: o modelo inline, onde markup e código coexistem no mesmo arquivo ASPX, e o modelo codebehind, que coloca markup em arquivos ASPX e código em arquivos código-fonte. O ASP.NET 2.0 introduz o terceiro modelo: uma nova forma de codebehind, que depende do novo suporte para classes parciais (partial class) dos compiladores Visual C# e Visual Basic. O codebehind do ASP.NET 2.0 resolve um problema antigo da versão 1.0: a necessidade de que classes codebehind contenham campos protected cujos tipos e nomes mapeiam para controles declarados no arquivo ASPX.

A Listagem 1 mostra o novo modelo codebehind. O arquivo Hello.aspx contém o markup e o Hello.aspx.cs contém o código. O atributo herdado da diretiva @Page identifica a classe codebehind, enquanto que o atributo CodeFile identifica o arquivo contendo a classe. Nota-se a ausência de qualquer campo na classe Hello fazendo mapeamento para controles do arquivo ASPX. O codebehind no estilo antigo, ainda é suportado, porém este novo modelo é atualmente o preferido. Não é de surpreender que o Visual Studio 2005 suporte os novos modelo nativamente.

 

Listagem 1. Codebehind 2.0

Hello.aspx

 

<%@ Page Language="C#" CodeFile="Hello.aspx.cs" Inherits="Hello" %>

 

<html>

  <body>

    <form id="form2" runat="server">

      <asp:TextBox ID="TextBox1" runat="server">asp:TextBox>

      <asp:Button ID="Button1" runat="server"

        OnClick="Button1_Click" Text="Button" />

      <asp:Label ID="Label1" runat="server">asp:Label>

    form>

  body>

html>

 

Hello.aspx.cs

using System;

using System.Web.UI;

using System.Web.UI.WebControls;

 

public partial class Hello : System.Web.UI.Page

{

    protected void Button1_Click(object sender, EventArgs e)

    {

        Label1.Text = TextBox1.Text;       

    }

}

Novo modelo de compilação dinâmica

Uma das muitas inovações introduzidas no ASP.NET 1.x, foi a capacidade do runtime de compilar código contido em arquivos ASPX. O ASP.NET 2.0 estende o modelo de compilação dinâmica, de modo que praticamente qualquer coisa pode ser automaticamente compilada.

Um diretório bin ainda está lá por questões de compatibilidade, porém agora é complementado por diretórios especiais chamados App_Code, App_GlobalResources e App_LocalResources. Os arquivos como código C# e Visual Basic contidos no diretório App_Code e os arquivos RESX no diretório de recursos são automaticamente compilados. Arquivos Web Services Description Language (WSDL) no diretório App_Code são compilados dentro de proxies de Web services;  arquivos XSD são compilados dentro de DataSets tipados. Esses diretórios podem ser estendidos para suportar também outros tipos de arquivo, via Web.config.

Precompilando e distribuindo sem código-fonte

Falando em compilações dinâmicas, uma das dúvidas mais comuns com relação ao ASP.NET 1.x, é se é possível precompilar páginas de forma a evitar a compilação inicial que ocorre na primeira vez que uma página é acessada. A resposta está no comando Build>Publish do Visual Studio 2005, que precompila um site inteiro e o distribui para as destinações escolhidas.

Uma outra característica bastante requisitada é a capacidade de precompilar sites inteiros em assemblies gerenciados, que podem ser distribuídos sem markup ou qualquer código-fonte, capacidade que é especialmente interessante em cenários onde a aplicação será hospedada em um servidor Web. O comando Publish Web Site do Visual Studio 2005 inclui uma opção chamada Allow this precompiled site to be updateable (“permitir que este site precompilado seja atualizável) que, caso seja desmarcado, precompila tudo (inclusive markup) e distribui arquivos ASPX sem qualquer conteúdo. A distribuição sem fonte não provê proteção a toda prova para nossa propriedade intelectual, pois qualquer um com acesso físico ao servidor, poderá ainda descompilar os assemblies gerados, porém representa uma barreira significativa para bisbilhoteiros de código.

Master Pages

Uma das mais conhecidas deficiências do ASP.NET 1.x, é a falta de suporte para templates de páginas. Não podemos definir uma página padrão que sirva com base (através de herança) para outras páginas. Os desenvolvedores contornam essa limitação compondo as páginas a partir de user controls, que são facilmente replicados de página para página, ou usando módulos HTTP e injetando código de interface comum para cada página apresentada.

Esses truques não são mais necessários no ASP.NET 2.0, graças às novas características conhecidas coma Master Pages. Pensemos em "herança visual" e compreenderemos o que são Master Pages. Primeiro definimos a Master Page contendo conteúdo que desejamos que apareça em outras páginas (as content pages) e a seguir, usamos controles ContentPlaceHolder para definir as localizações onde essas páginas podem exibir seus conteúdos. A seguir, construímos as content pages — arquivos ASPX — que referenciam a página master, usando diretivas como esta:

 

<%"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?