DevMedia
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
Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da .net Magazine DIGITAL
ou para quem possui Créditos DevMedia.

Clique aqui para saber como acessar este post

1) Torne-se um assinante MVP e por apenas R$ 69,90 por mês você terá acesso completo a todos os posts. Assinar MVP

2) Adquira Créditos: comprando R$ 180,00 em créditos esse post custará R$ 1,20. Comprar Créditos

post favorito     comentários

Revista MSDN Magazine Edição 09 - Personalização em ASP.NET 1.1

Analisaremos algumas extensões ASP.NET 1.1 que fornecem recursos de personalização ao runtime atual.

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você poderia comentar o que não lhe agradou?

Confirmo meu voto negativo

msdn09_capa.JPG

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

 

Personalização em ASP.NET 1.1

por Dino Esposito

Os aplicativos personalizáveis permitem que os usuários definam suas preferências de interface de usuário (UI) e armazenem essas configurações. Os aplicativos desktop geralmente armazenam as preferências do usuário em um arquivo local (arquivo XML ou de configuração) ou no Registro. Por outro lado, os aplicativos Web geralmente usam cookies para armazenar dados específicos ao usuário. Cookies são basicamente uma coleção de valores-chave baseados em texto enviada e recebida através de HTTP. Existem algumas desvantagens no uso de cookies — especificamente, no limite de tamanho (8 KB), na capacidade de o usuário recusar cookies e na natureza inerentemente insegura do texto sem formatação (embora você possa criptografar ou codificar o valor do cookie). Manter os dados personalizados no servidor é uma opção melhor, mas também tem seus problemas.

Analisarei algumas extensões ASP.NET 1.1 que fornecem recursos de personalização ao runtime atual. A API que pretendo descrever é inspirada na API de personalização do ASP.NET 2.0, mas não é uma cópia. A API de personalização do próximo ASP.NET 2.0, codename "Whidbey," não é excessivamente complexa mas é complexa demais para ser analisada em detalhes aqui.

 

Projetando uma camada de personalização

A camada de código que pretendo construir será destinada a trabalhar com um aplicativo que empregue um mecanismo de autenticação para autorizar seus usuários. No ASP.NET 1.1, você pode escolher entre vários modos de autenticação, tais como Passport e forms authentication. Se a camada de personalização detectar um usuário anônimo, ela não fará nada. O ASP.NET 2.0 fornecerá um recurso para lidar com situações em que tanto usuários anônimos como autorizados possam ser admitidos em um site.

A arquitetura da camada de personalização consiste principalmente em um módulo HTTP que precisa ser instalado e configurado pelo aplicativo. O módulo associa alguns eventos no nível do aplicativo — AuthorizeRequest e EndRequest — para carregar e salvar dados pessoais. A Figura 1 ilustra a arquitetura da API.

 

image001.gif

Figura 1 Minha API de personalização

 

Processar uma solicitação ASP.NET envolve várias etapas, e cada uma delas é caracterizada por um evento do aplicativo. Todos os eventos acionados durante o processamento de uma solicitação são associados com o objeto HttpApplication e não podem ser tratados pelo código em nível de página. Este código é apenas parte do ciclo de solicitação; conseqüentemente, nenhum código na página pode associar eventos do aplicativo. Para tratar eventos do aplicativo no nível do sistema, você precisa escrever um módulo HTTP.

O evento AuthorizeRequest é acionado quando a solicitação foi autenticada e a identidade por trás dela foi autorizada. Neste momento, o módulo usa o nome do usuário atual como um índice no data store — um banco de dados Microsoft® Access ou SQL Server™ — e recupera todas as informações pessoais relacionadas a ele. Essas informações deverão ser disponibilizadas de alguma maneira para o código da página. No ASP.NET 1.1, isso pode ser feito por meio da coleção Items do objeto HttpContext. No ASP.NET 2.0, foi adicionada uma nova propriedade à classe HttpContext, denominada Profile. A coleção Items da classe HttpContext é fornecida para que você possa preenchê-la com dados definidos pelo usuário. Programar a coleção Items é praticamente idêntico a programar o estado Session ou o objeto Cache:

 

Context.Items["BackColor"] = "gainsboro";

string color = (string) Context.Items["BackColor"];

 

Uma instância da classe HttpContext viaja com a solicitação durante todo o percurso e pode ser usada para compartilhar informações entre os módulos HTTP e a página. Assim, tudo que o módulo de personalização escreve no contexto é acessível à página e vice-versa. A página pode recuperar dados pessoais do contexto, processá-los e, se necessário, registrar as alterações. Quando o evento EndRequest é disparado, o módulo de personalização coleta os dados da coleção Items e os envia para a mídia.

Minha API oferece suporte tanto a um banco de dados Access como ao SQL Server para enviar dados específicos ao usuário, mas você pode usar qualquer data store. O ASP.NET 2.0 vai mais além, tornando o provedor de dados genérico e ocultando-o através de uma interface de provedor (provider interface). Você pode escrever (ou usar) qualquer componente e fazê-lo funcionar com qualquer tipo de armazenamento, desde que ele exponha os métodos de uma interface específica. No build do PDC, o ASP.NET 2.0 fornece provedores internos para Access (o padrão) e SQL Server. É importante notar que, se for usada uma mídia baseada em arquivo (como o Access), você precisará assegurar que o processo de trabalho (worker process) do ASP.NET possui as permissões apropriadas para gravar em um sistema de arquivos do Web server e, especificamente, no arquivo de dados. Você pode conceder essas permissões a um arquivo ou pasta usando a ferramenta cacls.exe, que é um componente padrão do sistema operacional Windows®. Você usa a seguinte linha de comando, substituindo [user] pelo nome da conta de usuário real:

 

cacls.exe [path] /E /G [user]:F

 

No caso de aplicativos ASP.NET, a conta de usuário precisará coincidir com a conta do processo que opera fisicamente no bando de dados — geralmente, o ASPNET ou NetworkService se você usar o Windows Server™ 2003. A mesma atribuição de permissões também pode ser obtida selecionando-se a guia Security na caixa de diálogo Properties do arquivo de banco de dados do Access.

 

O módulo http de personalização

Os módulos HTTP são classes que implementam a interface IHttpModule para tratar os eventos de runtime. Além dos eventos de sistema acionados pelo objeto HttpApplication, o módulo também pode tratar eventos acionados por outros módulos HTTP. Por exemplo, o módulo session state, um dos módulos ASP.NET internos, fornece serviços de estado de sessão para um aplicativo. Ele aciona os eventos End e Start que podem ser tratados por outros módulos através das assinaturas Session_End e Session_Start familiares. Os módulos HTTP têm uma funcionalidade semelhante à funcionalidade dos filtros ISAPI — DLLs Win32® que estendem IIS — porém com um modelo de programação muito mais simples, orientado a objetos. Os módulos HTTP filtram os dados brutos dentro de uma solicitação e são configurados de acordo com o aplicativo dentro do arquivo web.config. Todos os aplicativos ASP.NET herdam vários módulos HTTP de sistema, configurados no arquivo machine.config.

A interface IHttpModule define apenas dois métodos — Init e Dispose. Init inicializa o módulo e o registra para tratar os eventos de aplicativo relevantes. O método Dispose desfaz-se dos recursos usados pelo módulo. As tarefas que você geralmente realiza dentro deste método incluem a liberação de conexões do banco de dados e o tratamentos de arquivos. Os métodos da interface IHttpModule têm as seguintes assinaturas:

 

void Init(HttpApplication app);

void Dispose();

 

O método Init recebe uma referência ao objeto HttpApplication que está atendendo à solicitação. Você usa essa referência para preparar seu aplicativo para receber eventos do sistema. O objeto HttpApplication também apresenta uma propriedade denominada Context que fornece acesso às propriedades intrínsecas do aplicativo ASP.NET. Desse modo, você ganha acesso aos objetos Response, Request e Session. Você encontrará detalhes da implementação do modulo na Listagem 1.

 

Listagem 1 Módulo HTTP de personalização

namespace MsdnMag

{

  public class PersonalizationModule : IHttpModule

  {

    public void Init(HttpApplication app)

    {

      app.AuthorizeRequest += new EventHandler(OnEnter);

      app.EndRequest += new EventHandler(OnLeave);

    }

 

    public void Dispose()

    {

    "

A exibição deste artigo foi interrompida

Este post está disponível para assinantes MVP.



Dino Esposito (dino2@wintellect.com) é instrutor e consultor e reside em Roma, Itália. Dino é autor de Building Web Solutions with ASP.NET and ADO.NET e Applied XML Programming for Microsoft .NET, ambos da Microsoft Press (2002).

O que você achou deste post?
Publicidade
Serviços

Mais posts