As armadilhas do ViewState

Desde que surgiu a idéia de desenvolver aplicações utilizando a Web, uma das principais motivações para tanto foi o fato de aplicações Web se comportarem como aplicações cliente-servidor onde os clientes se comportam efetivamente como thin-clients, sendo desnecessária a instalação de qualquer aplicação no cliente além do próprio Browser.

Surgiram linguagens cada vez mais avançadas e com elas frameworks proporcionalmente mais sofisticadas para desenvolver aplicações Web, possibilitando o acesso facilitado à bancos de dados, aumentando a produtividade, e assim proporcionando formas melhores de desenvolver tais aplicações. Uma das frameworks que surgiu foi a .NET, e esta por sua vez trouxe um recurso bastante interessante para armazenar o estado dos controles de uma página, o View State.

Em suma, o View State consiste em serializar objetos dentro do código html de uma página em uma parte específica do mesmo, criptografando os objetos que nele são armazenados. O grande problema está no fato de que muitos programadores vem utilizando o view state para armazenar objetos de negócio em detrimento do uso de recursos tradicionais como as sessões, algo que pode ser mortífero caso a complexidade desse objeto seja muito grande.

O maior argumento está no fato de que muitas vezes objetos são armazenados em sessão e nem sempre são removidos da mesma, acumulando “lixo” na memória do servidor.

Porém ocorre que, uma sessão dura o tempo que o navegador do cliente estiver aberto, ou então, o tempo estabelecido para que ocorra o timeout da mesma, e os objetos armazenados em sessão não são enviados do servidor para o cliente, não gerando tráfego na rede, e assim livrando o cliente de baixar alguns bytes ou mesmo megabytes de dados.

O problema do uso desregrado de View State se torna ainda maior quando se trabalha com persistência OO (leia-se NHibernate, Linq to SQL, DB4Objects), quando a programação se torna realmente orientada a objetos e objetos complexos são carregados do banco de dados e armazenados temporáriamente no View State. Para exemplificar imagine as seguintes situações:

1. Um objeto Rua. Esse objeto possui 2 atributos, sendo estes o Id e o Nome. Se armazenarmos este objeto no View State teremos apenas um objeto simples, o que não traz maiores problemas.
2. Um objeto Bairro. Esse objeto possui 3 atributos, sendos estes o Id, o Nome, e Ruas, que é uma lista de Ruas. Se supormos que este objeto Bairro contém 100 Ruas e estamos armazenando o mesmo no View State, na verdade estaremos armazenando 101 objetos. Okay, isto pode ser muito pouco, não é mesmo?
3. Um objeto Cidade. Esse objeto possui 3 atributos, sendos estes o Id, o Nome, e Bairros, que é uma lista de bairros. Suponhamos que cada bairro possua 100 ruas, e que existam 93 bairros, como na cidade de São Paulo. Vamos à matemática: (100 + 1) x 93 + 1 = 9394 objetos.

Isso mesmo, 9.394 objetos para serem armazenados no código fonte do cliente.

Como um exercício sugiro o seguinte:

Crie uma página, e crie os mesmos objetos que descrevemos acima, com as mesmas propriedades, e faça um método que gere um objeto cidade contendo 93 bairros, que contenham 100 ruas cada um. Após criado este objeto armazene o mesmo na View State da sua página. Após isso veja o código HTML que foi gerado na página do cliente e procure pela tag VIEWSTATE.

Ficou muito grande?

Use o View State com muita cautela, e tenha certeza do seguinte: é muito melhor armazenar 9394 objetos na memória do servidor que enviar tudo isso para o SEU cliente.