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.

O que é camarão?

Quase todos os dias eu acompanho as estatísticas desse enfadonho blog, e dia desses me deparei com uma situação extranha:

Ao olhar para os termos do motor de busca havia uma pergunta – “O que é camarão?”

A intriga vem não pelo fato de que a pessoa que parou nesse blog estava a procurar algo que não tem nenhuma relação com os assuntos aqui abordados, porém pelo falo dessa pessoa estar procurando algo que parece óbvio.

De certa forma resolvi responder a esta pergunta, mesmo que tardiamente.

Segundo o dicionário WorkPedia segue a definição:

s.m. Zoologia Nome dado a diversos crustáceos decápodes comestíveis. / Vaso de louça antigo. / Gancho que se fixa no teto para suspender lustres, armações etc.

Se a definição acima não satisfizer, ainda existem outros sites que trazem algumas informações mais precisas, como esta da Wikipedia. Não vou descrevê-la pois é muito extensa.

Na gíria de alguns também camarão pode definir a erva que contém o princípio Canabis Sativa, a popular Maconha.

Na música vem a frase “Camarão que dorme a onda leva”… da qual não sei o que significa camarão, mas também não estou interessado nisso. A única coisa que me intriga é o fato de haver no mundo uma pessoa que não tem a mínima idéia do que é camarão… Talvez seja pra isso que exista a Internet.

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.

Wiimote like para X-Box 360

Bom… é bem assim.. aquela coisa que começa e já é esperado que aconteça:

1. Alguém faz alguma coisa legal e que todos acham que é matadora.
2. Todo mundo pensa que ninguém vai copiar, pois tem uma patente X, que diz tal coisa e tal outra.
3. Mas aí vem um nojentinho sem escrúpulos, desalmado (oh) que vai e mosta que todos estão errados.

-É isso que vai acontecer agora com o Wii, né?

-É.

Se você olhar aqui o que eles escreveram, tá escrito isso. Nas entrelinhas, mas tá.

Eles dizem que a Microsoft está em contato com uma empresa chamada Gyration, detentora da patente da tecnologia do Wiimote, ou seja, ela está licenciando a tecnologia revolucionária do Wii para o X-Box 360.

A MTV.com ainda faz questão de frisar e deixar bem explícito que quem disse isso foi o mesmo cara que disse que a Bungie se tornaria uma empresa separada.

Acredito que agora a nintendo vai ter que mudar sua aposta: um videogame para a família, porém com tecnologia de sobra para ter ótimos gráficos e etc e tal.

Eu também disse que o zune não faria sucesso (pelo menos no Brasil até agora não fez) e que o Blu-ray ia comer o HD-DVD com arroz e feijão…

A imagem ao lado é um suposto esboço do brinquedinho… talvez ele também se chame XMote, ou algo do gênero. (to só tentando prever o futuro previsível)