Cara estava pensando em manter o estado de algumas classes em campos hidden no lugar de colocar na sessão.
Isso traria melhor escabilidade ao sistema (ou não ?)
como o ViewState do ASP .NET.
Já fiz e dá certinho.
Como isto funciona:
Serializo a classe em um array de bytes e depois com o algoritimo de base64 tranformo em uma string.
Cara fica bala. uma string pequenininha.
Jogo isso em um campo hidden.
Para recuperar faço o processo inverso.
O código todo não dá 20 linha.
Mas minha pergunta.
Isso causaria problemas de processamento? Em toda requisição eu faço isso.
Pelo que vejo é um processamento rápido e sem custos.
O problema é saber se ao serializar uma classe o java não consome muitos recursos.
Em termos de recursos, vai ser bem mais dispendioso que deixar na session. Da mesma forma, voce tem mais trabalho para serializar e fazer o processo inverso que simplesmente adicionar / pegar da sessao.
Pq voce nao quer deixar na sessao? Eh tanta informacao assim que uso de memoria seria grande?
Campos hidden poderiam ser usados para isto mas não foram criados para isto.
Sessões são muito práticas mas a gente deve evitar guardar muita coisa lá a menos que seja um sisteminha caseiro com 3 ou 4 clientes e nunca vá crescer mais do que isto. Além de mau desempenho fica uma caca para fazer manutenção. Guardar classes serializadas na sessão é coisa assustadora para mim.
Existe a questão da segurança, já que seus clientes vão ter acesso a estrutura interna do teu sistema.
Fora isso, é uma media meio radical serializar boa parte do estado da sessão em um campo hidden. Isso só faz algum sentido se o sistema vai rodar em um cluster ou o número de sessions simultâneas vai ser grande o suficiente para esse estado a mais causar um OOM no servidor.
Outra coisa, serialização é um processo meio carinho.
O problema não é o código, mas como louds falou o preço do processamento. É esta minha pergunta.
O código é muito simples como disse dá 20 linhas.
Enquanto poder ou não usar campos hidden, eu acho que pode sim.
Porque não?
Muitos autores aconselham guardar o estado em hidden.
É excelente.
Enquanto a segurança não tem problema, são informaçoes da própria tela, ou seja, não seria louco de colocar informações que não poderia ser vistas.
O campo hidden recebe um valor totalmente ilegível.
Quem conhece o algorítimo base64 sabe que ele retorna uam string
“XZERTGFHUIYTIKHFGDFGCCXXE…”
Quem usa isso é o ASP.NET
É só entrar em um site ASP.NET e exibir o HTML e procurar __VIEWSTATE
Só que no ASP.NET é enorme, pois ele matém o form inteiro.
Colocar muita coisa na sessão pode ser perigoso, nunca gostei muito disso.
E por falar nisso como o struts mantém o estado dos forms.
Eu acho que é na sessão. Nunca parei para pesquisar.
Estava um pouco preocupado com isso num sistema aqui, pois estava guardando bastante informação na sessão dos usuários. Então fiz um mini stress-test logando 400 usuários na aplicação. Não aumentou nem em 10k o consumo de memória do server.
Fazer esse tipo de otimização ser ter uma boa razão eu acho estranho.
Não desista da sua idéia. É muito interessante, principalmente se você tiver de escrever um sistema com milhares de usuários simultâneos - o que não é incomum se o seu cliente é um banco ou uma loja de departamentos, por exemplo.
Obviamente você sempre deve tomar cuidado com a segurança - se você tem alguma CPU para gastar, pode sempre deixar os dados cifrados com uma chave derivada do id da sessão e de uma chave secreta no servidor alterada periodicamente, usando algum algoritmo (AES, por exemplo) no modo CFB ou OFB para facilitar. Assim, mesmo que alguém fique fuçando o que está no campo hidden, não terá muito o que fazer.
Lipe, fui eu que levantei esta restrição de não se colocar muitas coisas na sessão. Guardando muita coisa o servidor pode chegar ao ponto de precisar de swap na memória (q não foi seu caso). Um exemplo de como se pode evitar isto é guardar apenas a chave primária na sessão ao invés de toda a linha da tabela.
É tudo uma questão de boas práticas. O cara se acostuma a colocar tudo na sessão e no dia em que a aplicação precisar rodar em cluster vai ser um parto fazer a coisa funcionar. Por causa desta possibilidade de rodar em cluster é que se recomenda que tudo que vai para a HttpSession seja serializable para permitir a replicação com armazenamento em arquivo. Procure também por “server affinity”.
As regras que adoto com uso de sessions são:
Não criar estado a menos que realmente seja necessário
Minimizar o volume de dados guardados na sessão
Usar objetos pequenos granularizados ao invés grandes blocos monolíticos
Quanto a usar campos hidden, a ideía é válida mas eu ainda acho meio complicado de administrar pois coloca na view coisas que o designer não consegue entender. E ainda tenho outras restrições:
Todos os objetos precisam ser convertidos
Não podemos navegar de uma página para a outra, sempre precisamos de form com JavaScript ao invés de hiperlinks simples
Com cookies, se o usuário fecha o browser, ainda posso ter seu estado mantido caso necessite disto.
Enquanto o designer entender, não há problema, pois isso é feito dinamicamente.
E também tem isso com as sessions.
São portaveis em ambiente de cluster.
Mas os objetos devem ser serializaveis.
Já pensei também em fazer uma gambiarra com os listeners para guardar no banco.
A ideia do campo hidden seria para manter informações entre requisiçoes do mesmo form não entre forms.
Por exemplo grids, tabelas, campos.
Para dar submit na tela sem ter que refazer consultas.
Uma espécie de cash no client.
Agora compartilhar entre forms diferentes fica meio complicado.
Mas pelo que percebi o STRUTS guarda o estado dos forms na session.
Alguém sabe me dizer ?
Se isso for verdade pode ser um risco a escalabilidade de acordo com nossa discussão.
Luca, concordo com todos os pontos que você levantou. Mas injetando o objeto via IoC, fica fácil mudar o escopo dele para qualquer coisa pertinente
jprogrammer isso que você falou sobre cache no cliente me parece perigoso. Serializar uma coleção grande de objetos e guardar tudo num input me dá medo hehe
[quote=LIPE]Mas também não necessariamente pequenas oras
E não conheço ninguém doido o bastante para fazer caching na sessão hehe[/quote]
Numa aplicacao com (1) quantidade de dados pequena por cliente, (2) numero grande de clientes simultaneos e (3) necessidade de buscar os dados em mainframe, optamos por essa estrategia. Ainda mantenho minha sanidade (nao tao intacta, mas mantenho :D).
Aqui na empresa, temos uma WebControl no framework desenvolvido por nós, do qual ele faz um processo semelhante, serializa, seta como hidden, você poderá pegar por qualquer página, pois virá submissão, e isso em base64.
Grinvon
Você me confortou.
Não sou o único louco a ter a essa ideia.
Ela é viável.
Vocês desenvolveram seu próprio framework, diga quais os problemas e quais as vantagens para o pessoal ver que não é um bicho de 7 cabeças.
Porque sempre que alguém toca nesse assunto o pessoal mete o pau e confunde “criar um framework customizado” com “criar tudo do zero”.
O que não é verdade. nínguém é louco de fazer isso.
