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.

Notificações por E-Mail no Team Foundation Server 2008

O TFS possui um recurso de enviar alertas de Work Items para membros da equipe, porém a configuração dos mesmos é bem espartana, principalmente quando se usa um servidor SMTP com autenticação.

Certa vez eu estava procurando uma solução e achei este post, onde há um serviço fácilmente configurável para o Team Foundation Server. O serviço funciona muito bem e sua configuração é bem simples. Toda vez que se cria um work item, ou que se muda o “assigned to” de um work item chega um e-mail para a pessoa que recebeu o work item.

Se você for mais audacioso da ainda para alterar o corpo ou título dos e-mails através de arquivos XSLT.

É importante lembrar que os e-mails dos colaboradores devem estar devidamente configurados no Active Directory, mas se não estiverem basta vigiar o arquivo de log gerado pelo serviço.

Fica aí a dica.

5 coisas que o Visual Studio não tem… e o Eclipse tem…

Há bastante tempo o Eclipse despontou como uma ferramenta extremamente poderosa para desenvolvedores, suportando diversas linguagens e sendo idolatrado pela comunidade Java. Sendo uma solução Open Source, muitos dos seus recursos podem ser alterados ou até mesmo utilizados por outros desenvolvedores para diversas finalidades.

Inegávelmente o Visual Studio é uma IDE com diversos recursos interessantes, e em sua essência une o melhor de vários mundos. Primeiramente a sua raiz RAD que veio da forma de pensar dos seus engenheiros, que foram comprados da “Borland” onde desenvolviam o ex-aclamado Delphi. Depois, outros recursos como a idéia de se integrar recursos e ferramentas terceiras dentro de um único ambiente, que surgiu do Eclipse.

A verdade é que nem o Eclipse é perfeito, e nem o Visual Studio, porém pelo fato de o Visual Studio ser uma ferramenta paga (e muíto cara), eu acredito fortemente que alguns recursos que são disponíveis no Eclipse (que é Open Source) poderiam ser reescritos para o Visual Studio (atualmente na versão 2008) :

1 – Depuração de código Just In Time, ou sei lá como se chama – enquanto você escreve seu código o Eclipse vai compilando o mesmo e avisando possíveis erros, e erros de verdade. Erros de verdade quando realmente não dá pra ser certo, como castings incorretos ou a ausência do tratamento de excessões. Possíveis erros quando por exemplo, se declara uma variável mas não se atribui valor a ela.

2 – Generate Getters and Setters – No .net, não existem Getters e Setters, porém existem as propriedades, que nada mais são que Getters e Setters disfarçados. Há sim uma forma de gerar as propriedades para um atributo, mas você necessita de gerar cada uma individualmente, e com pouquíssimas opções, enquanto no Eclipse é possível selecionar todos os atributos em uma lista e gerar todas, com várias opções… e põe várias nisso…

3 – Generate Constructors – Essa é uma coisa que eu acho fenomenal… é simples e direta, mas é fenomenal por isso mesmo. Imagine que você quer fazer uma classe e facilitar a vida dos outros programadores dando a estes um conjunto de 20 construtores. Agora imagine ter que escrever cada um destes construtores. No Eclipse podem ser gerados os contrutores selecionando quais os atributos que serão usados nestes. Isso é simples, mas é matador.

4 – Os métodos são seus próprios templates – Uma coisa que me deixa extremamente irritado com o Visual Studio é quando você usa o auto-complete e ele não coloca nem ao menos os parênteses do método. No Eclipse quando você digita um método e usa o auto-complete, automáticamente ele já cria os parênteses e os espaços para se preencher os parâmetros do mesmo. Pode fazerser pouco mas faz uma grande diferença.

5 – Editor de XML visual – é uma coisa legalzinha você poder visualizar o seu XML como uma estrutura e não uma linguagem de programação.

Não tenho intenção de levantar bandeiras. Como disse anteriormente, só estou questionando o motivo pelo qual o Visual Studio ainda não copiou os recursos do eclipse, que é Open Source.

Caso alguém tenha mais algum questionamento  que não foi citado, me envie.