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.

É hoje!

Hoje vou finalmente apresentar meu TCC. Já estou angustiado por isso, mas com certeza no fim será gratificante.

No meu projeto eu desenvolvi um sistema de gerenciamento acadêmico em duas versões, sendo que a primeira utiliza Banco de Dados Relacional MySQL, e a segunda utiliza o Banco de Dados OO Db4Objects.

No fim das contas, para cada função do sistema que foi implementada criei um quadro constando todas as classes que foram utilizadas para fazer a persistência do objeto, todos os métodos, e a quantidade média de linhas para se persistir. Dessa foi consegui enxergar que com Banco de Dados OO as funções foram implementadas com muuuuuuuuuuuuito, mas muuuuuuuuuuito mais facilidade que com banco relacional.

Depois vou postar um exemplo aqui no blog pra quem quiser conhecer melhor o Db4Objects.