Uso de Session

[Thiago Aguiar]

Minha duvida eh como organizar o uso dela dentro da aplicação.

em meus trabalhos sempre foi feito o uso controlado, colocando uma classe que fazia o acesso a um objeto na Session, e todo mundo só fazia uso dele, assim não ficava uma bagunça que todo mundo criando variáveis na sessão e deixando lá, com apenas um objeto ficava meio que "forçado" um pouco de organização.

Só que em tela complexas que tem muito uso da session normalmente fazendo ate navegação em passos (outras telas) a coisa complica, por exemplo, a tela guardava apenas um int na session, que era passado inclusive para outra tela..., agora com uma mudança vai ser necessário armazenas alem do int, uma outra informação qualquer, que vai ser usado apenas na pagina atual ou em uma terceira tela.....

Pronto lá vai um hash na session, e ficamos livres para guardar qualquer coisa. E nesse ponto que começa a falta de organização.... isso tudo era feito nos modelo antigos que conheci.

Agora to montando um ambiente novo, e com relação a esse problema não achei nada que ajude com relação ao uso de session, alguém pode me passar alguma informação sobre isso, ou dar um exemplo de como vocês usam a Session.

Eu to com uma ideia aqui, mas tenho medo de querer colocar muita coisa e apenas deixa o processo complicado, sem ganho na organização.

Lembre que o problema maior eh como organizar os dados para uma "navegação", normalmente usado em telas com vários passos

"Existem apenas 10 tipos de pessoas no mundo - aquelas que entendem binário, e aquelas que não."

Thiago Aguiar

[edmilson hora]

Neste caso eu usaria Cookie  guardado todas as informações necessárias para passar de tela para tela. Uma outra abordagem vc mesmo já citou,  colocar um  objeto complexo na session e trafegar a session atraves de Uma classe com um metodos staticos.

Tipo Assim:

 public class SuperSessionCliente
    {
        public static void GuardarSessionCliente(Cliente cliente)
        {
            HttpContext.Current.Session["cliente"] = cliente;
        }

        public static Cliente ObterSessionCliente()
        {
            if (HttpContext.Current.Session["cliente"] == null)
                throw new Exception("Session Cliente não Inicializada");

            return (Cliente)HttpContext.Current.Session["cliente"];
        }

    }


    public class Cliente
    {
        public int Id { get; set; }
        public string Nome { get; set; }
        public DateTime DataCadastro { get; set; }
    }

---

De: Thiago Aguiar <thiag...@gmail.com>
Para: dotnetar...@googlegroups.com
Enviadas: Domingo, 1 de Abril de 2012 11:25
Assunto: [dotnetarchitects] Uso de Session

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Daniel Moreira Yokoyama]

Cookies realmente são a melhor escolha, eles ficam no client e são enviados no request.

Desta forma vc pode ficar despreocupado com o estado da sessão.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Thiago Aguiar]

meu problema não eh onde e sim como guardar.

mas valew pelo retorno.

"Existem apenas 10 tipos de pessoas no mundo - aquelas que entendem binário, e aquelas que não."

Thiago Aguiar

2012/4/2 Daniel Moreira Yokoyama <moreira....@gmail.com>

[Marco Aurelio]

Você poderia usar tambem cache... é uma boa... ja vi e fiz muitas coisa com cache...

Atenciosamente,

Marco Aurélio O. Souza
spm...@gmail.com
55 11 8887-5831

[Rene Felix Correa]

Marco,

Não acho legal guardar em cache pois, pelo que eu saiba, variáveis de cache são únicas para a aplicação e não para cada sessão que o usuário abre uma nova sessão.Se alguem tiver duvidas segue um link que pode ajudar: link

Tiago,

Aonde trabalhei tambem sempre foi de costume criar uma classe estática para setar e recuperar o valor de variaveis da session, atuamente não conheço outra forma de fazer

2012/4/5 Marco Aurelio <spm...@gmail.com>

--
Rene Felix Correa
Analista Desenvolvedor
http://renefc3.wordpress.com

[Bruno Gallego]

Eu parei de usar session faz um tempinho. Session só se for do NH.

mas vc disse:

"uma outra informação qualquer, que vai ser usado apenas na pagina atual ou em uma terceira tela....."

* Se é usado apenas na página, nao use session. use viewstate, cookie ou campo hidden.

Viva o stateless !  :)     
* sem esquecer do relay attack

[Thiago Aguiar]

viewstate nunca mais :)

seguinte...

cookie ou hidden eh levado para o cliente...trafego de rede, segurança mesmo criptografado(mais trafego)

então eu pago um pouco de memoria, só tem q ser organizado se não fica uma merda.

"Existem apenas 10 tipos de pessoas no mundo - aquelas que entendem binário, e aquelas que não."

Thiago Aguiar

2012/5/17 Bruno Gallego <bruno...@gmail.com>

[Juan Lopes]

Memória de servidor é recurso mais escasso que banda, em geral. Se você salva 10kb em objetos por sessão de usuário (o que é um valor baixo, visto o que andam colocando na sesion por ai), quando você tiver 100 mil clientes conectados, serão 1GB de memória só pra session. E não estou falando de acessos simultâneos. Estou falando de 100 mil em um dia, que não é um valor absurdo.

Session dificulta o sharding transparente, pois uma vez que um cliente acessa um servidor ele precisa sempre voltar ao mesmo servidor nos requests subsequentes. E isso causa problemas sérios quando o cliente está atrás de um NAT mal configurado. Isso vai fazer seu site parar de funcionar.

Como consequencia do motivo acima, escalar usando session state é mais difícil.

Além disso, a serialização do .NET é absurdamente lenta. Então você vai gastar tempo de processador (que é mais escasso ainda) para manter um estado que você vai precisar desserializar a cada request. A viewstate tem o mesmo problema.

2012/5/17 Thiago Aguiar <thiag...@gmail.com>

--
https://github.com/juanplopes

[Thiago Aguiar]

pouco..

a session eh limpa em tempos e tempos, a não ser q eu tenha 100mill usuário Ativos, mesmo assim eu com 100mill usuário ativos eu vou achar pouco 1gb

para escalar servidor web, com session eu nunca fiz, mas pelo que eu li era fácil, já que o session já fica em outro serviço.

com relação a serializar, posso ta falando errado mas acho que ele usa BinaryFormatter, que eh rápido e compacto, porem incompatível com outras tecnologias(Java.....)

"Existem apenas 10 tipos de pessoas no mundo - aquelas que entendem binário, e aquelas que não."

Thiago Aguiar

2012/5/17 Juan Lopes <m...@juanlopes.net>

[dm.ga...@gmail.com]

Você pode ter um servidor somente para session (aspnet_wp). Um gb de memória não eh nada nesse cenário. Agora eu só não estou certo se ele serializa em binário ou não, porém acho que não faria sentido serializar em xml.  

Eu já usei o APPFabric como um servidor de sessão, replicando os dados em casa nó. Requerimento que a sessão jamais fosse perdida caso um servidor falhasse. 

E cache sem replicação para dados que eram passiveis de reconstrução. 

Só não aconselho a usar o AppFabric, não achei maduro o suficiente....

Deivison M. Gandini
dm.ga...@gmail.com | msn: dm_ga...@hotmail.com
Before printing, think about your responsibility and commitment to the ENVIRONMENT!
Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE!

2012/5/17 Thiago Aguiar <thiag...@gmail.com>