Cadastre-se Revistas DevMedia Cursos
 

Space de DEYVISSON CARLOS BORGES DE MELO
Busca Autor


Últimas 20 atualizações de DEYVISSON CARLOS BORGES DE MELO

Artigo - Gerenciamento de estado: como manter informações entre requisições no Asp.Net

1. Gerenciamento de estado: Como manter informações entre requisições no Asp.Net

Diferentemente das aplicações Windows, aplicações web não mantem o estado da conexão, ou seja, nenhuma informação gerada no processo de comunicação é armazenada. Toda vez que for realizada uma requisição, o servidor não saberá de quem é a solicitação e nem se esse usuário já visitou o site antes. Além do fato de que após cada processamento e envio de páginas, todos os recursos alocados e utilizados são destruídos para preservação da memória do servidor. Este é um procedimento importante, pois em um ambiente web, o servidor deve atender várias solicitações simultâneas, e para isso, deve possuir recursos suficientes, recursos esses que são recuperados com a destruição dos objetos utilizados.

Neste cenário não é possível, por exemplo, armazenar o nome de um usuário e utilizá-lo em outras páginas, pois a aplicação não poderá manter a informação. Para contornar esse problema, o Asp.Net disponibiliza alguns mecanismos para o armazenamento e gerenciamento do estado da aplicação, sendo possível implementar em aplicações web, um comportamento semelhante ao gerenciamento de estado das aplicações Windows.

2. Gerenciamento de estado no cliente x servidor

O Asp.Net utiliza dois tipos de gerenciamento de estado: gerenciamento no cliente e no servidor. Cada tipo possui procedimentos diferentes para trabalhar com a informação que deve ser armazenada.

No modo cliente, todas as informações são armazenadas no computador que gerou a requisição, assim, a cada solicitação, todas as informações devem ser enviadas ao servidor, e após processadas, reenvidas para o armazenamento no cliente. No segundo modo, todas as informações são mantidas no servidor, apenas um código é transmitido na comunicação para identificar o cliente.

Adiante seguem imagens ilustrando o procedimento utilizado para cada modo de gerenciamento:

Gerenciamento do estado da aplicação no cliente

Figura 1: Gerenciamento do estado da aplicação no cliente

Gerenciamento do estado da aplicação no servidor

Figura 2: Gerenciamento do estado da aplicação no servidor

Alguns requisitos devem ser levados em conta na hora de decidir qual tipo de gerenciamento se adequa melhor para cada situação. Cada tipo possui seus prós e contras, e a escolha de um ou outro irá depender do que é mais crítico para sua aplicação.

Se escalabilidade é um fator importante, onde a aplicação deve atender o máximo de requisições simultâneas possíveis, deve-se escolher o gerenciamento no lado do cliente. O armazenamento das informações no cliente evita a sobrecarga da memória do servidor, pois este não precisa guardar as informações de cada usuário que solicitar uma página, deixando assim, mais espaço em memória para atender outras solicitações.

Outro ponto que favorece o lado do cliente é a possibilidade de se utilizar diferentes web services. Com o gerenciamento no servidor, de modo padrão, não é possível a utilização direta de múltiplos servidores, pois a informação está armazenada em um único ponto, e se no meio de uma transação for necessária a troca, este novo servidor não terá nenhuma informação a respeito do usuário.

Se a segurança é um ponto crítico na aplicação, o armazenamento no servidor é mais recomendado por ser mais seguro. As informações não serão transmitidas através da rede, e não estarão disponíveis para fácil manipulação na máquina do cliente. Assim, deve-se evitar guardar dados sensíveis no cliente, como senhas, perfis de acesso e demais dados sigilosos, essas informações estarão mais seguras dentro do servidor.

No modo cliente as informações são transmitidas e retransmitidas a cada requisição, com isso uma largura de banda maior é necessária para realização do processo de comunicação. Se a aplicação precisar armazenar muita informação é aconselhável a utilização do servidor, pois a transmissão desses dados pode onerar a comunicação tornando o carregamento de páginas mais lento, aumentando a largura de banda necessária para execução da aplicação.

A escolha de um método não exclui a possibilidade da utilização do outro, seu sistema muito provavelmente utilizará uma mistura dos dois tipos. Para cada funcionalidade deve-se escolher o método que melhor atende os requisitos de execução, atentando para o que é crítico para sua aplicação.

3. Gerenciamento no cliente

Conforme exposto no item anterior, o gerenciamento de estado no cliente é utilizado quando se deseja economizar recursos do servidor, aumentando assim sua escalabilidade e disponibilidade. Para realizar este tipo de gerenciamento o Asp.Net disponibiliza quatro mecanismo de armazenamento, a View state, os Hidden fields, os Cookies e as Query strings. As seções seguintes abordam cada um em detalhes:

3.1. View state

A View state é um recurso nativo do Asp.Net, utilizado pelos controles para armazenar suas propriedade entre postbacks, ou seja, somente utilizada para guardar dados entre requisições de uma mesma página.

Armazenada em um Hidden Field, denominado “__VIEWSTATE”, seu conteúdo é codificado em uma string de base 64 e, em cada requisição, é enviada ao servidor para ser consultada sobre a configuração atual das propriedades da página e dos controles existentes. Abaixo um exemplo de como pode ser observada em uma página padrão.

Listagem 1: Exemplo de Hidden Field

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE"  value="/GuvXiuykijhk...=">

Para ter acesso a seu conteúdo, basta utilizar a propriedade da página “Page.ViewState”, que corresponde a um dicionário de objetos do tipo StateBag. Sua utilização é bastante simples, onde cada objeto possui um identificador único para acesso ao valor armazenado.

Listagem 2: Utilizando a propriedade ViewState

ViewState["Cor"] = Color.Black;

if (ViewState["Cor"] == null)
Cor = (Color)ViewState["Cor"];

O exemplo acima configura a variável “Cor” dentro da ViewState. Aqui dois pontos importantes são demonstrados, o primeiro é a necessidade de verificar a existência de valor dentro do dicionário, pois caso aconteça o acesso a uma variável nula, o sistema gerará uma exceção NullReferenceException. Outro ponto é o casting necessário toda vez que for utilizar um valor armazenado, isto acontece porque a ViewState converte todos os dados para o tipo “Object”, este procedimento permite o armazenamento de qualquer tipo de dados que

...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
09/10/2012 13:03:00





Artigo - Trabalhando com Page Output Caching no Asp.Net

No artigo anterior, falei sobre o Application Caching, mecanismo capaz de armazenar objetos na memória do servidor para otimizar o acesso de novas requisições. Neste artigo irei abordar a segunda formar de caching disponibilizada pelo Asp.Net, o Page Output Caching.

Neste tipo de caching páginas ou seções dela são armazenadas na memória, com isso, novas solicitações não terão que realizar todo processamento para geração da página, o servidor simplesmente envia o HTML armazenado para o cliente que efetuou a requisição.

1. Passo a passo de uma requisição com Asp.Net

Para explicitar os benefícios do caching em páginas Asp.Net será mostrada as etapas de uma requisição web padrão, e compará-las com as etapas de uma requisição a uma página que já está em cache.

A imagem abaixo demonstra os eventos que ocorrem desde a solicitação do usuário no browser até a resposta do servidor, para uma página que não está em cache.

Passo a passo de uma requisição sem utilização do Output Caching

Figura 1: Passo a passo de uma requisição sem utilização do Output Caching.

O processo começa com a requisição do cliente. Ao chegar ao servidor, a página é encontrada e enviada ao Parse do Asp.Net, onde o código fonte será interpretado gerando instruções que serão enviadas para o compilador. Este é responsável por gerar o Assembly da página, que depois de criado é enviado para a memória do Runtime HTTP, onde as instruções serão executadas gerando a página solicitada. Quando uma segunda solicitação é realizada, as etapas de interpretação e compilação são puladas, pois o Assembly já está criado no servidor.

Agora imagine uma aplicação web com inúmeros clientes, cada cliente requisitando a mesma página que demanda um considerável processamento para sua criação, mas que não muda com tanta frequência. Para cada requisição todo o processamento visto anteriormente será necessário, se houverem 1000 requisições, 1000 vezes será executado, mesmo se o conteúdo não mudar.

A próxima imagem demonstra uma requisição a uma página que está no cache. Podemos notar a economia de recursos do servidor ao utilizar o Output Caching. Após a primeira requisição o conteúdo será armazenado em cache e todas as solicitações subsequentes receberão apenas o conteúdo HTML que já está armazenado, não sendo necessário o processamento da página.

Passo a passo de uma requisição com utilização do Output Caching

Figura 2: Passo a passo de uma requisição com utilização do Output Caching.

2. Ativando o caching de página

Para ativar o mecanismo de caching em páginas .aspx é necessário informar no topo da página a diretiva @OutputCache da seguinte forma:

Listagem 1: Informando diretiva @OutputCache no Topo da Página

<%@ OutputCache ... %>

Essa diretiva possui vários parâmetros e de acordo com suas configurações vários resultados e comportamentos podem ser obtidos. As seções seguintes mostram como obter esses diferentes resultados.

2.1. Definindo o tempo de duração do caching

Para definir o tempo em que o cache de uma página é válido basta informar um valor inteiro para o parâmetro Duration, o valor informado irá corresponder ao tempo em segundos que a página estará em cache. Este é um parâmetro obrigatório, se não informado irá gerar uma exceção em runtime. O exemplo adiante ativa o caching da página por um tempo de trinta segundos.

Listagem 2: Definindo tempo de validade do caching

<%@ OutputCache Duration="30" VaryByParam="none"%>

2.2. Definindo a localização do caching

Outra configuração possível é informar onde o caching será armazenado. Configurando a propriedade Location é possível informar se o caching estará no cliente, no servidor ou em servidores proxy que participarem da solicitação. Os seguintes valores são possíveis:

  • Any: O caching pode ser armazenado em qualquer mecanismo participante da requisição. Browser, servidores de proxy e o próprio servidor web;
  • Client: Armazenado apenas no browser do cliente onde a solicitação foi originada;
  • Downstream: Armazenado em qualquer dispositivo HTTP 1.1 que possui capacidade de cache e que participou da requisição, incluindo o cliente;
  • Server: O caching estará armazenado apenas no servidor web que processou a requisição;
  • None: Desabilita o caching;
  • ServerAndClient: Armazena o caching apenas no servidor que processou a requisição e no cliente que a realizou, não permitindo o armazenamento em servidores proxy que por ventura tenham participado do processo.

O exemplo abaixo mostra como ativar o caching com duração de 10 segundos e armazená-lo apenas no servidor web.

Listagem 3: Ativando caching com duração de 10 segundos

<%@ OutputCache Duration="10" VaryByParam="none" Location="Server"%>

2.3. Parâmetro NoStore

A diretiva OutputCache possui ainda o parâmetro NoStore, que serve para informar aos browsers e servidores proxys, participantes da requisição, que não devem armazenar uma cópia permanente da página. É geralmente utilizado em páginas que possuem conteúdo sensível, como páginas de login. Configurado da seguinte maneira:

Listagem 4: Configurando OutputCache

<%OutputCache Duration="30" VaryByParam="none" NoStore=”true” %>

2.4. Armazenamento em cache de acordo com a QueryString

Existem cenários em que as páginas devem mudar seu conteúdo de acordo com parâmetros passados pela QueryString, mas apesar da mudança, o conteúdo específico de cada página/parâmetro não muda com frequência. Para esses cenários é possível utilizar o caching configurando o parâmetro VaryByParam, que consiste em uma lista de strings separadas por ponto-vírgula, indicando os parâmetros passados pela QueryString que devem ser considerados no cache. Observe o exemplo a seguir:

Listagem 5: Cache variável por parâmetro

<%@ OutputCache Duration="3600" VaryByParam="Id" %>

Neste exemplo acima, o caching foi ativado levando em consideração o parâmetro “Id”, passado via QueryString. Quando o servidor receber solicitações de uma página informando esse parâmetro, para cada valor passado será armazenada uma página no caching. Para cada uma das requisições abaixo o resultado da página irá ser armazenado no cache:

Listagem 6: Requisições para altrar o cache por parâmetro

PageOutputCaching/VaryByParam.aspx
PageOutputCaching/VaryByParam.aspx?Id=1
PageOutputCaching/VaryByParam.aspx?Id=2

O parâmetro VaryByParam é obrigatório, se não quiser utilizá-lo deve-se informar o valor “none”. Para informar que todos os parâmetros passados devem ser considerados no caching utiliza-se o valor “*”. Porém devemos evitá-lo, pois para cada combinação de valores enviados para os parâmetros, uma página será armazenada em cache, com isso o espaço em memória reservado poderá rapidamente ficar escasso e outras informações mais importantes serem removidas.

2.5. Armazenamento em cache de acordo com controles da página

Assim como ocorre com a variação pela QueryString, é possível armazenar páginas em cache de acordo com os valores dos controles utilizados no Asp.Net. Para fazer isto basta configurar o parâmetro VaryByControl informando uma lista de ID’s dos controles que devem ser considerados no caching. Quando se utiliza o VaryByControl não é necessário informar o VaryByParam. O exemplo abaixo mostra como configurar o caching para que para cada valor selecionado e submetido do DropDowList “ddlTema” seja armazenada uma versão da página em cache.

Listagem 7: Cache variável por controle

<%--Configuração--%>
<%@ OutputCache Duration="1000000" VaryByControl="ddlTema" %>

2.6. Armazenamento em cache de acordo com parâmetro customizado

Também é possível, através de um valor customizado, definir como será o armazenamento em cache. Deve-se configurar o parâmetro VaryByCustom na página com um identificador, e no arquivo Global.asax sobrescrever o método GetVaryByCustomString, informando como deve ser realizado o processo. Abaixo um exemplo de como criar um caching da página de acordo com o método de requisição (Get ou Post).

Na página:

Listagem 8: Configurando a página para cache customizado

<%@ OutputCache Duration="1000000" VaryByParam="none" VaryByCustom="metodo"%>

Global.asx:

Listagem 9: Configurando o Global.asax para cache customizado

public override string GetVaryByCustomString(HttpContext context, string custom)
{
      if (custom == "metodo")
                return context.Request.RequestType;
      else
             return base.GetVaryByCustomString(context, custom);
}

2.7. Armazenamento em cache de acordo com cabeçalhos HTTP

Outra forma de mudar o comportamento do caching é configurando o parâmetro VaryByHeader, que recebe uma lista de propriedades enviadas com os cabeçalhos HTTP. Configurando esse parâmetro, par

...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
05/07/2012 00:00:00





Artigo - Implementando Caching no Asp.Net

Ao se realizar uma requisição à um servidor web, toda uma cadeia de eventos é realizada para geração e renderização da página e recursos solicitados. Se uma página contém recursos que demandam um grande processamento, como exemplo uma consulta robusta a base dados, a cada requisição todo o processamento deverá ser realizado, mesmo se não houver nenhuma alteração nas informações coletadas. Logo, se a página acessa informações que não mudam frequentemente fica evidente o gasto desnecessário de recursos do servidor.

Para contornar essas situações, seria interessante a utilização de um mecanismo que nos permitisse armazenar as informações necessárias e só exigisse o processamento para obtenção do recurso quando fosse realmente necessário.

O Asp.Net provê este mecanismo através do caching, técnica que permite que objetos ou até mesmo páginas inteiras sejam armazenadas em memória, permitindo assim um rápido acesso ao conteúdo requisitado e sem a necessidade de lidar com complexidades como gerenciamento de memória ou atualização e expiração das informações em cache.

Este artigo tenta mostrar de forma simples como utilizar o caching no Asp.Net para aumento de desempenho e escalabilidade das aplicações web.

Tipos de caching

O Asp.Net provê dois tipo de caching: o caching de aplicação (Application caching) e o de página (Output Page caching). A seguir, uma definição dos dois:

  • Application caching: Funciona como uma lista de objetos armazenados na memória, basicamente como os objetos de gerenciamento de estado Session ou Aplication. Os itens armazenados a lista possuem escopo de aplicação, ou seja, são compartilhados por todas na aplicação web.
  • Page output caching: Este tipo de caching armazena páginas renderizadas, porções da página ou versões dela. Quando utilizado, a requisição recebe uma cópia que está na memória, não sendo necessário nenhum processamento para geração da mesma.

Application caching

O cahcing de aplicação é o processo de armazenar objetos na memória para acesso rápido, evitando a necessidade de processamento para obtenção dos resultados. Este tipo de caching pode ser utilizado de forma idêntica aos objetos Session ou Application. Como eles, consiste em uma lista de objetos referenciados por uma chave e pode ser acessado através da propriedade Cache do objeto Page. Adiante um exemplo de sua utilização:

Listagem 1: Application caching

public partial ApplictionCaching : System.Web.UI.Page
{
	protected void Page_Load(object sender, EventArgs e)
	{
		if(Page.Chace["DataHora"] == null)
			Page.Cache["DataHora"] = DateTime.Now;
		lblTime.Text = ((DateTime)Page.Cache["DataHora"]).ToLongTimeString();
	}
}

Note no exemplo acima, que assim como o objeto Session é necessário realizar o cast para o determinado tipo de objeto no ato da extração da informação. Além disso, todo objeto inserido possui um escopo global, sendo compartilhado por toda aplicação entre seções e requisições.

Método Insert

O Asp.Net através do método Insert provê uma forma mais sofisticada para implementar este tipo de caching. Habilitando controle a preciosas funcionalidades como tempo limite para expiração das informações, dependência de caching com outros objetos, configuração de prioridade e função de callback para o evento de remoção. Adiante um exemplo da utilização do método Insert:

Listagem 2: Método Insert

Page.Cache.Insert("DateTime", DateTime.Now);

Este exemplo mostra a forma mais simples de utilização do método, mas é possível realizar operações de caching mais sofisticadas. A seguir, as funcionalidades adicionais do método Insert:

Dependência de caching:

É possível vincular o período em que a informação no cache é válida através da relação com outros objetos. Um exemplo seria que uma determinada informação em cache só é valida até que um determinado arquivo no servido não seja atualizado, quando for, será necessário atualizar o conteúdo do cache. Essa funcionalidade é possível através da configuração do parâmetro dependencies, este parâmetro é um objeto CacheDependency, pertencente ao namespace System.Web.Caching.

O exemplo a seguir mostra como realizar o caching do conteúdo de um arquivo de texto e configurar a dependência de modo que quando o arquivo de texto for alterado o objeto será removido do cache.

Listagem 3: Caching de conteúdo

//Caching com depend

...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
02/07/2012 00:00:00





 

Analista de Sistema na Vale.
Arquivo de atualizações
 2012

Estatísticas do Autor:
Número de posts: 3
Características dos posts deste autor:
Conteúdo:
Utilidade:
2 0
 
DevMedia Group - Tel: (21) 3382-5038 - www.devmedia.com.br
Todos os Direitos Reservados a DevMedia Group