12. Manutenção de Estado
Em aplicação que não mantêm estado por natureza, como nossas
aplicações web, utilizamos alguns mecanismos para manter as informações
importantes para nosso negocio entre uma requisição e outra. O IIS por sua vez
incorpora um cookie com um identificador único no cabeçalho de cada requisição
http, que é enviada de volta pelo navegador. Esse cookie que torna possível
identificar um mesmo usuário entre os diversos “vai e volta” de uma aplicação
Web.
Desta forma a cada requisição poderíamos gravar em um banco de
dados às informações importantes daquele momento, vamos supor o nome do
usuário. Na próxima requisição pegamos novamente este identificador único e
faríamos uma consulta em no banco de dados, já saberíamos de qual usuário se
trata, poderíamos então armazenar neste momento as informações de um produto
que o usuário resolver comprar e assim a vida seguiria tranquilamente.
Esta é uma forma primitiva e árdua de manter estado, existem
diversas outras técnicas, todas com seus prós e contras, é o que vamos estudas
nas próximas sessões.
Profiles
Manter informações em variáveis de sessão é um dos recursos
mais simples e utilizados para manter o estado de uma aplicação Web:
Armazenamos as informações importantes em variáveis de sessão. A aplicação faz
automaticamente a associação entre o Identificador Único explicado na sessão
anterior e as varias de sessão do mesmo.
No ASP.NET 2.0 o recurso de personalization tornou isso mais
fácil. Agora, podemos gerenciar informações de forma mais intuitiva e fácil,
com ajuda inclusive do Intelissense.
Um exemplo simples
Vamos começar com um exemplo simples, para isso crie uma
aplicação ASP.NET. Esta aplicação será usada durante todos os exemplos deste
capitulo.
Crie duas páginas em sua aplicação: Inicial.aspx e Final.aspx.
Na primeira coloque um controle TextBox e um Controle Button de texto Enviar e
na outra um controle label.
Altere seu arquivo web.config, incluindo um nó profile da
seguinte forma:
|
<profile>
<properties>
<add
name="Nome"/>
</properties>
</profile>
|
|

|
Ao final deste capitulo você pode encontrar o web.config
na sua versão final.
|
De um duplo clique no botão Enviar e adicione o seguinte:

|
Profile.Nome = TextBox1.Text
Response.Redirect("Final.aspx")
|

|
Profile.Nome = TextBox1.Text;
Response.Redirect("Final.aspx");
|
No evento Load da pagina Final.aspx:

|
Label1.Text = Profile.Item("Nome")
|

|
Label1.Text =Convert.ToString(
Profile["Nome"]);
|
Note que o qualquer propriedade que você definir no profile
estará disponível no intellisense:

Turbinando a propriedade
Você pode ainda definir algumas características de uma
propriedade de um profile, como tipo e valores padrão. Veja o web.config
anterior agora com a propriedade nome definida como string e com valor padrão
igual a Anônimo:
|
<profile>
<properties>
<add
name="Nome" type="System.String"
defaultValue="Anônimo" />
</properties>
</profile>
|
Definindo Grupos
Outra funcionalidade é organizarmos nossas propriedades em grupos. No nosso exemplo vamos adicionar um grupo Endereco, para armazenar o logradouro,
número, cidade e estado do usuário:
|
<profile>
<properties>
<add
name="Nome" type="System.String"
defaultValue="Anônimo" />
<group
name="Endereco">
<add
name="Logradouro"/>
<add
name="Numero"/>
<add
name="Cidade"/>
<add
name="Estado"/>
</group>
</properties>
</profile>
|
Adicione mais três controles textbox na pagina Inicial.aspx
para que o usuário digite estas novas propriedades:

Altere o código do botão enviar de acordo com o exemplo a seguir:

|
Profile.Nome = TextBox1.Text
Profile.Endereco.Logradouro = TextBox2.Text
Profile.Endereco.Numero = TextBox3.Text
Profile.Endereco.Cidade = TextBox4.Text
Profile.Endereco.Estado = TextBox5.Text
Response.Redirect("inicial.aspx")
|

|
Profile.Nome = TextBox1.Text;
Profile.Endereco.Logradouro = TextBox2.Text;
Profile.Endereco.Numero = TextBox3.Text;
Profile.Endereco.Cidade = TextBox4.Text;
Profile.Endereco.Estado = TextBox5.Text;
Response.Redirect("inicial.aspx");
|
Já nosso evento Load na página Final.aspx devera ficar assim:

|
Label1.Text = Profile.Nome & " " & _
Profile.Endereco.Logradouro & " " & _
Profile.Endereco.Numero & " " & _
Profile.Endereco.Cidade & " " & _
Profile.Endereco.Estado
|

|
Label1.Text = Profile.Nome + " " +
Profile.Endereco.Logradouro + " " +
Profile.Endereco.Numero + " " +
Profile.Endereco.Cidade + " " +
Profile.Endereco.Estado;
|
Session
Como explicado algumas sessões atrás, uma das formas mais
simples de manutenção de estado é através de variáveis de sessão. Cada variável
esta associada ao cookie de identificação do usuário. Por padrão, estas
informações estão armazenadas no próprio processo do ASP.NET. Uma novidade da
era .NET foi a possibilidade de armazenamento de informações de sessão em um processo
separado (um servidor de estado) ou até mesmo em um SGBD. Isto trouxe novos horizontes ao desenvolvimento de aplicações Web em ASP.NET, pois
simplificou a criação dos chamados Web Farms, termo que define um conjunto de
servidores rodando uma aplicação especifica.
|

|
Em nosso curso vamos estudar apenas o gerenciamento de
sessão no próprio processo do ASP.NET (inProc), que é o comportamento padrão.
|
Uma variável de sessão esta associada a exclusivamente a uma
única sessão. Isto significa que um dado armazenado em uma variável de nome X
para o usuário João não será visível na variável de sessão de mesmo nome do
usuário Pedro, e vice-versa.
Para testarmos o uso de variáveis de sessão, vamos criar uma
pequena aplicação que vai armazenar um valor em uma variável e exibi-lo em
outra página. Em seguida vamos rodar uma outra instancia da mesma aplicação
para verificar que os valores armazenados diferem de uma instancia para outra.
Para isso crie uma nova aplicação ASP.NET com duas páginas: Inicial.aspx e Final.aspx.
Na primeira coloque um controle TextBox e um Controle Button de texto Enviar e
na outra um controle label.
De um duplo clique sobre o botão enviar e no manipulador de
evento criado insira o seguinte código:

|
Session("Nome")
= TextBox1.Text
Response.Redirect("Final.aspx")
|

|
Session["Nome"]
= TextBox1.Text;
Response.Redirect("Final.aspx");
|
No evento Load da página Final.aspx insira a
código abaixo:

|
Label1.Text = Session("Nome")
|

|
Label1.Text = Session["Nome"];
|
|

|
O identificador de uma variável de sessão é sensível a
diferenciação entre letras maiúsculas e minúsculas, portanto Nome representa
uma variável e nome outra.
|
Defina Inicial.aspx como pagina inicial, rode a
aplicação, digite um valor na caixa texto e observe o valor ser exibido na
página seguinte.
Você tambem pode armazenar qualquer tipo de
objeto em uma variavel de sessão.
HiddenField
Uma das formas mais simples e antigas de manter estado dentro
de uma mesma página é através de campos ocultos. O valor atribuído ao controle
é mantido na propriedade value entre post backs, porém não é renderizado na
página.
ViewState
Imagine a seguinte situação: em um determinado
ponto de um cadastro o usuário, após informar diversos dados cadastrais, tem
que digitar o CEP para que o sistema faça a busca do endereço. O post back é
acionado e quando a requisição volta ao navegador, todos os dados digitados se
perderam em algum lugar do cyberspace. Claro que ninguem vai criar um
aplicativo com desta forma, porém o exemplo é para lembrar que no ASP classico
e em outras diversas linguagens de programação para Web, devemos manter o
estado da página manualmente, ou seja, digitando muitas linhas de código.
No ASP.NET o recurso de ViewState mantem
automaticamente os valores de controles de servidor entre um post back e outro.
Na verdade o ViewState internamente nada mais é do que uma campo oculto um
pouco mais sofisticado. Se você rodar uma aplicação ASP.NET sem qualquer
controle verá que é criado um campo oculto para o armazenamento do ViewState:
|
<input type="hidden"
name="__VIEWSTATE" id="__VIEWSTATE"
value="/wEPDwUJNzgzNDMwNTMzZGS8mO25pQR00V4slvgSxG3dEvK+hA==" />
|
Note que os dados não são exibidos em texto plano, por
questões de segurança. Porém este é um recurso palhativo e não devemos utilizá-lo
para manter dados sensíveis.
Você ainda pode usar o ViewState para adicionar “manualmente”
valores ao ViewState, lembrando que você vai conseguir recuperá-los apenas
entre um post back e outro na mesma página. Abaixo um pequeno exemplo de
atribuição de um valor ao ViewState:

|
ViewState("Nome") = "Fernando
Amaral"
|

|
ViewState["Nome"] = "Fernando
Amaral";
|
QueryString
Outro modelo clássico de manutenção de estado é o através do
uso de querystrings, que nada mais são do que conjuntos de pares/valores
anexados a URL, provavelmente você já deve ter visto dezenas de páginas usando
este recurso.
Sua utilização é simples, após a URL você adiciona o primeiro
valor na forma ?Chave=Valor. Para passar mais de um conjunto, os mesmos devem
ser concatenados através do caractere &. Para recuperar o valor na outra
página basta usar Request.QueryString.
Crie uma nova aplicação ASP.NET com duas páginas: Inicial.aspx
e Final.aspx. Na primeira coloque dois controles TextBox, um para digitação do
nome e outro para idade e um Controle Button de texto Enviar e na outra um
controle label.
Para montar a URL de redirecionamento com as duas variáveis:

|
Response.Redirect("Final.aspx?"
& "Nome=" & TextBox1.Text
& "&Idade=" &
TextBox2.Text)
|

|
Response.Redirect("Final.aspx?"
+ "Nome=" + TextBox1.Text + "&Idade=" + TextBox2.Text);
|
Para recuperar os valores na pagina seguinte:

|
Label1.Text = Request.QueryString("Nome") & "
" & Request.QueryString("Idade")
|

|
Label1.Text = Request.QueryString["Nome"] + "
" + Request.QueryString["Idade"];
|
Cookies
Outra forma de manutenção de estado é através do uso de
cookies, que nada mais é do que um pequeno arquivo de texto que armazenado na
maquina do usuário. Sua grande vantagem é que você pode identificar o usuário
mesmo dias depois de seu acesso a página. Este recurso é muito usado, pro
exemplo, em sites de comercio eletrônico, para exibir as preferências do
usuário os últimos produtos que ele navegou.
O grande problema dos cookies é que o usuário simplesmente
pode desabilitar este recurso em seu navegador.
Cross Page Postback
Uma nova funcionalidade do ASP.NET a partir da versão 2.0 é
capacidade de recuperação de informações entre diferentes páginas. Este recurso
já foi visto em nosso primeiro módulo.
Application
Semelhante em diversos aspectos com variáveis de sessão, com
uma importante diferença: As variáveis de aplicação são compartilhadas entre
todas os usuários da aplicação. Uma variável de aplicação esta associada a toda
a aplicação. Isto significa que um dado armazenado em uma variável de nome X
para o usuário João será visível na variável de aplicação de mesmo nome do
usuário Pedro, e vice-versa.
Outra diferença importante é que uma variável de aplicação
estará disponível durante toda a vida da aplicação, enquanto uma variável de
sessão será perdida ao fim da sessão do usuário.
Crie uma nova aplicação ASP.NET com duas páginas: Inicial.aspx
e Final.aspx. Na primeira coloque um controle TextBox para digitação do nome e
um Controle Button de texto Enviar e na outra um controle label.
Na página Incial.aspx digite o seguinte código no manipulador
de evento criado no botão Enviar (observe que não há redirecionamento):

|
Application("Nome")
= TextBox1.Text
|

|
Application["Nome"]
= TextBox1.Text;
|
No evento Load da pagina Final.aspx digite o seguinte código:

|
Label1.Text = Application("Nome")
|

|
Label1.Text = Application["Nome"];
|
Para testar, defina Inicial.aspx como página inicial, informe
seu nome e clique no botão enviar. Feche a aplicação e vá tomar um copo de
água. Na volta, defina Final.aspx como pagina inicial, rode a aplicação e
observe o resultado.
|

|
Você pode ser perguntar como foi possível recuperar o
valor já que ninguém estava usando a aplicação em determinado momento. Na
verdade, mesmo que ninguém utiliza a aplicação, os valores de variáveis de
aplicação só serão perdidos quando a última sessão expirar.
|
Caching
Aplicações web podem ter de atender centanas de
milhares de usuários, e temos que usar todos os recursos disponíveis para
mante-la rodando com uma boa performance.
Normalmente alguns recursos são exibidos a
diferentes usuários sem sequer que tenha havido tempo para estas informações
serem alteradas. De qualquer forma, se nada for feito, a cada acesso a
aplicação vai novamente buscar essas informações onde quer elas estejam. Para
citar um exemplo, se seu aplicativo em uma pagina de cadastro exibe uma relação
de cidades em um ComboBox para que o usuário faça a escolha de uma. A cada novo
usuário sua aplicação vai abrir uma conexão com o banco de dados, executar a
consulta e preencher o ComboBox. Qual o custo desta tarefa para sua aplicação?
Qual a probabilidade da relação de cidades mudar nas proximas horas?
O ASP.NET nos oferece diversos recusos de
armazenamento em cache, vamos estada-los a seguir.
Output Caching
A adicão de uma diretiva de compilação em uma
página ASP.NET já vai colocar a página em cache. Para fazer um teste, coloque a diretiva a seguir logo abaixo da diretiva @Page:
|
<%@ OutputCache Duration="30" VaryByParam="None"
%>
|
Coloque um label em sua página e no evento Load digite o
código abaixo:

|
Label1.Text = DateTime.Now.ToString
|

|
Label1.Text = DateTime.Now.ToString();
|
Rode a aplicação. Observe a hora exibida. Pare a aplicação e
rode novamente ou simplismente atualize a página. Veja que a hora continua a
mesma, sem atualização.
Aguarde em torno de 30 segudos, que foi o tempo de duração
informado na diretiva e rode a aplicação novamente. Observe que a hora é
atualizada.
Variação por Parametros
O atributo VaryByParam, utilizado no exemplo anterior nos
permite criar versões diferentes para variações de determinado parâmetro na
Query String da aplicação.
Para exemplificar, no exemplo anterior altera a diretiva da
seguinte maneira:
|
<%@ OutputCache Duration="30" VaryByParam="Codigo"
%>
|
Rode a aplicação e adicione a ?Codigo=1 ao final da Url, como
no exemplo abaixo:

Memorize a hora, altere o código para 2 e tecle Enter. Note
que hora mudou. Volte o valor do parâmetro para 1 e tecle Enter. Note que é
exibido a hora anterior, ou seja, que estava armazenada em cachê.
“Você pode especificar o armazenamento por mais de um
parâmetro, bastando para isso informa-los separados por ”;”. O armazenamento se
dará sempre pela combinação de todos os parâmetros, ou seja, sempre que surgir
uma nova combinação de valores, um novo armazenamento será gerado. Para que
seja aplicado cache a todos os parâmetros, basta informa “*”.
VaryByControl
Através do atributo VaryByControl, podemos definir que
determinado controle da página seja armazenado em cachê, bastando para tanto
informar o nome do mesmo:
|
<%@ OutputCache Duration="30" VaryBycontrol="Label1"
%>
|
O uso de VaryByControl é ideal para o armazenamento de User
Controls.
Substitution
As vezes queremos manter em cache a página inteira, porem
determinada informação precisa ser dinâmica e variar de usuário pra o usuário
ou mesmo em função do tempo. Um bom exemplo é exibir a hora atualizada pro
usuário, ou mesmo seu nome de login.
O ASP.NET disponibiliza para isso um controle Subtituton, que
recebe na sua propriedade MetodName o nome de um método que será dinâmico, ou
seja, não será armazenado em cache. Este método deve deve ser shared /static e
receber como parâmetro um tipo HttpContext.
Adaptar o nosso primeiro exemplo, em que exibimos a data e
hora em label, para ter uma porção da página exibindo a hora sem armazendo em
cache, utilizando um Substitution, é facil. Primeiramente adicione a seguinte
função a página:

|
Public Shared Function
RetornaHora(ByVal context As HttpContext) _
As
String
Return DateTime.Now.ToString()
End Function
|

|
public static string
RetornaHora(HttpContext context)
{
return DateTime.Now.ToString();
}
|
Em seguida acione um controle Subtitutio e denina sua
propriedade MethodName como RetornaHora.
Rode a aplicação. Atualize a página algumas vezes e note que o
Label colocado anteriormente mantem fixo o valor da hora enquato o cache não
espira. Já o controle Substitution renderiza a data e hora atualizados.

Programando cache manualmente
Para poder aproveitar o Maximo da funcionalidade de cache,
você pode programar a sua utilização. O funcionamento básico é semelhante ao de
variáveis de sessão e aplicação, basta ler ou gravar o valor através de um
identificador único:

|
Cache("Nome") = "Fernando"
|

|
Cache["Nome"] =
"Fernando";
|
Outra maneira de utilizar cache é usando o método Insert. O
primeiro parâmetro é o identificador, o segundo é o abjeto a ser armazenado:

|
Cache.Insert("Nome",
"Fernando")
|

|
Cache.Insert("Nome",
"Fernando");
|
O método Insert possui ainda algumas sobrecargas, que permitem
criar dependências, ou determinar o tempo de expiração do cache. O tempo de
expiração pode ser absoluto, onde você deve informar a hora exata em que o
cache vai expirar, ou sliding, em que você informa o tempo de expiração a
partir da criação do cache. O exemplo abaixo coloca um string em cache por 20
segundos:

|
Cache.Insert("Nome",
"Fernando", Nothing, DateTime.MaxValue,_
TimeSpan.FromSeconds(20))
|

|
Cache.Insert("Nome","Fernando", null,
DateTime.MaxValue, TimeSpan.FromSeconds(20));
|