Realizando testes com um sistema on-line reparei que mesmo operacoes simples como envio de pequenos textos estavam levando muito tempo. O motivo principal, uma conexao muito lenta.Isso poderia acabar aqui, no entanto, uma conexao lenta nao e um problema do cliente e sim de quem desenvolve o sistema. Analisando os dados enviados e recebidos, encontrei o mais provavel culpado: ViewStates.Para aprofundar um pouco a respeito do seu uso encontrei um site excelente que ajudou inclusive a entender melhor a dinamica das paginas ASP.NET.Minha conclusao a respeito e, so usar ViewStates quando estritamente necessario. Facil falar mas nao tao facil de implementar ja que alguns de meus controles utilizam esse recurso. Hoje me lembrei de uma solucao interessante que utilizei a algum tempo atras para o classico problema de armazenar as preferencias dos usuarios. Sei que a solucao e antiga, mas, como ainda ha programas muitos programas por ai que insistem em gravar dados no Registro do Windows, resolvi documentar.A solucao mais correta para armazenar configuracoes do usuario e na pasta de dados de aplicacao (AppData) dentro da pasta Meus Documentos.Existe uma classe base que facilita muito a implementacao dessa funcionalidade sem ter que recorrer a formatos personalizados, sintaxes complexas e leitura e escrita de arquivos. A classe ApplicationSettingsBase facilita a implementacao de classes que armazenam parametros de forma tipada.Utilizei essa solucao e, de fato, e muito simples, pratica e segura. Nada como o bom uso de bibliotecas.Como exemplo, segue o codigo que fiz:using System;using System.Collections.Generic;using System.Text;using System.Configuration;namespace CapturaVideo{ public class Configuracoes : ApplicationSettingsBase { public Configuracoes() { } [UserScopedSetting] public Dispositivo EntradaVideo //Classe dispositivo deve ser [Serializable] { get { return (Dispositivo)this["EntradaVideo"]; } set { this["EntradaVideo"] = value; } } [UserScopedSetting] public Dispositivo EntradaAudio { get { return (Dispositivo)this["EntradaAudio"]; } set { this["EntradaAudio"] = value; } } [UserScopedSetting] public Dispositivo EncoderVideo { get { return (Dispositivo)this["EncoderVideo"]; } set { this["EncoderVideo"] = value; } } [UserScopedSetting] public Dispositivo EncoderAudio { get { return (Dispositivo)this["EncoderAudio"]; } set { this["EncoderAudio"] = value; } } }} Passei o dia incomodado com a modelagem do banco de dados de um sistema em que estou trabalhando. O problema e que fizemos o banco de dados generico que utiliza uma tabela para 3 tipos diferentes de dados e outra para mais 5 tipos. Ha colunas chamadas ID_ITEM1, ID_ITEM2 e ID_ITEM3 que podem ser nulas e que fazem referencia a diferentes cadastros dependendo da coluna TP_DESTINO.Isso e bastante generico e e um sintoma de modelagem ruim. Nao quero ser purista, mas essas colunas simplesmente nao dao nenhum sentido aos dados que contem.Fizemos isso porque ha elementos que sao comuns diversas tabelas independente do tipo. Pesquisando um pouco encontrei uma excelente solucao para esse problema. Achei essa solucao elegante, infelizmente, aumenta o numero de tabelas de duas para dez. Bom, quantidade de tabelas nao e exatamente um problema. A biblioteca Microsoft Enterprise Library 5.0 oferece alguns recursos muito interessantes.Por exemplo, a biblioteca Data que permite listar objetos diretamente da base de dados de forma bem simples. Para mais detalhes, ha um livro excelente.Utilizando os metodos DataBase.ExecuteSqlStringAcessor<TResult>() ou DataBase.ExecuteSprocAcessor<TResult>() e possivel mapear