PHP: Armazenando 'objetos' dentro do $ _SESSION

Acabei de descobrir que posso realmente armazenar objetos no $ _SESSION e acho muito legal porque, quando pulo para outra página, ainda tenho meu objeto. Agora, antes de começar a usar essa abordagem, gostaria de descobrir se é realmente uma boa idéia ou se existem armadilhas potenciais envolvidas.

Sei que se eu tivesse um único ponto de entrada, não precisaria fazer isso, mas ainda não estou lá, por isso não tenho um único ponto de entrada e realmente gostaria de manter meu objeto porque não não perco meu estado assim. (Agora também li que devo programar sites sem estado, mas ainda não entendo esse conceito.)

Então, em suma : É OK para armazenar objetos na sessão, há algum problema com ele?

Editar:

Resumo temporário : A essa altura, eu entendo que provavelmente melhor recriar o objeto, mesmo que isso envolva a consulta do banco de dados novamente.

Talvez mais respostas possam ser elaboradas sobre esse aspecto um pouco mais!

Sei que esse tópico é antigo, mas esse problema continua aparecendo e não foi abordado para minha satisfação:

Se você salvar objetos em $ _SESSION ou reconstruí-los com base em dados armazenados em campos de formulário ocultos, ou consultá-los novamente no banco de dados toda vez, você está usando state. O HTTP é sem estado (mais ou menos; mas veja GET vs. PUT), mas quase tudo o que alguém se importa com um aplicativo da Web exige que o estado seja mantido em algum lugar. Agir como se empurrar o estado para cantos e recantos equivale a algum tipo de vitória teórica é errado. Estado é estado. Se você usa o estado, perde as várias vantagens técnicas obtidas por não ter estado. Isso não é algo para se perder o sono, a menos que você saiba com antecedência que deveria estar perdendo o sono por causa disso.

Estou especialmente desconcertado com a bênção recebida pelos argumentos de "golpe duplo" apresentados por Hank Gay. O OP está construindo um sistema de comércio eletrônico distribuído e com balanceamento de carga? Meu palpite é que não; e ainda afirmo que a serialização de sua classe $ User, ou qualquer outra coisa, não prejudicará seu servidor além do reparo. Meu conselho: use técnicas que sejam sensíveis à sua aplicação. Objetos em $ _SESSION são bons, sujeitos a precauções de bom senso. Se seu aplicativo se transformar repentinamente em algo que rivaliza com a Amazon no tráfego atendido, você precisará se adaptar novamente. Isso é vida.

tudo bem, desde que a chamada session_start () seja feita, a declaração / definição da classe já foi encontrada pelo PHP ou pode ser encontrada por um carregador automático já instalado. caso contrário, não seria possível desserializar o objeto do armazenamento da sessão.

HTTP é um protocolo sem estado por um motivo. Sessões soldam o estado no HTTP. Como regra geral, evite usar o estado da sessão.

UPDATE: Não há conceito de sessão no nível HTTP; os servidores fornecem isso fornecendo ao cliente um ID exclusivo e solicitando que o reenvie a cada solicitação. Em seguida, o servidor usa esse ID como chave em uma grande hashtable de objetos Session. Sempre que o servidor recebe uma solicitação, ele procura as informações da Sessão em seus hashtable de objetos de sessão com base no ID que o cliente enviou com a solicitação. Todo esse trabalho extra é um golpe duplo na escalabilidade (uma grande razão pela qual o HTTP é sem estado).

• Whammy One: reduz o trabalho que um único servidor pode fazer.
• Whammy Two: torna mais difícil o dimensionamento, porque agora você não pode simplesmente encaminhar uma solicitação para qualquer servidor antigo - eles nem todos têm a mesma sessão. Você pode fixar todas as solicitações com um determinado ID de sessão no mesmo servidor. Isso não é fácil e é um ponto único de falha (não para o sistema como um todo, mas para grandes partes de seus usuários). Ou então, você pode compartilhar o armazenamento da sessão em todos os servidores do cluster, mas agora tem mais complexidade: memória conectada à rede, um servidor de sessão independente etc.

Dado tudo isso, quanto mais informações você colocar na sessão, maior será o impacto no desempenho (como Vinko aponta). Também como Vinko aponta, se o seu objeto não for serializável, a sessão se comportará mal. Portanto, como regra geral, evite colocar mais do que o absolutamente necessário na sessão.

@Vinko Geralmente, você pode contornar o estado de armazenamento do servidor incorporando os dados que está rastreando na resposta que você envia de volta e fazendo com que o cliente os reenvie, por exemplo, enviando os dados para baixo em uma entrada oculta. Se você realmente precisa do rastreamento de estado no servidor, provavelmente deve estar no seu armazenamento de dados de backup.

(Vinko acrescenta: o PHP pode usar um banco de dados para armazenar informações da sessão e fazer com que o cliente reenvie os dados a cada vez pode resolver possíveis problemas de escalabilidade, mas abre uma grande lata de problemas de segurança que você deve prestar atenção agora que o cliente está no controle de todos seu estado)

• Objetos que não podem ser serializados (ou que contêm membros não serializáveis) não sairão do $ _SESSION como seria de esperar
• Sessões enormes sobrecarregam o servidor (serializar e desserializar megas de estado cada vez que é caro)

Fora isso, não vi problemas.

Na minha experiência, geralmente não vale a pena por algo mais complicado do que um StdClass com algumas propriedades. O custo da desserialização sempre foi mais do que recriar de um banco de dados, devido a um identificador armazenado em sessão. Parece legal, mas (como sempre), a criação de perfil é a chave.

Eu sugeriria não usar o estado, a menos que você absolutamente precise. Se você pode reconstruir o objeto sem usar sessões, faça-o. Ter estados em seu aplicativo da Web torna o aplicativo mais complexo para criar, para cada solicitação que você precisa ver em que estado o usuário está. É claro que há momentos em que você não pode evitar o uso da sessão (por exemplo: o usuário deve manter o login durante a sessão em o aplicativo da web). Por último, sugiro manter o objeto da sessão o menor possível, pois isso afeta o desempenho para serializar e desserializar objetos grandes.

Você precisará lembrar que os tipos de recursos (como conexões db ou ponteiros de arquivo) não persistirão entre os carregamentos da página e será necessário recriá-los invisivelmente.

Considere também o tamanho da sessão, dependendo de como ela é armazenada, você pode ter restrições de tamanho ou problemas de latência.

Eu também mencionava ao atualizar as bibliotecas de software - atualizamos nosso software e a versão antiga tinha objetos em sessão com os nomes de classe do software V1, o novo software estava travando quando tentava criar os objetos que estavam na sessão - como o V2 o software não usava mais essas mesmas classes, não as encontrava. Tivemos que inserir algum código de correção para detectar objetos da sessão, excluir a sessão, se encontrada, recarregar a página. A maior dor inicialmente lembrou que você estava recriando esse bug quando foi relatado pela primeira vez (familiar demais, "bem, funciona para mim"), pois afetava apenas as pessoas que entravam e saíam dos sistemas novos e antigos recentemente - no entanto, bom trabalho que encontramos antes do lançamento, pois todos os nossos usuários certamente teriam as variáveis ​​de sessão antigas em suas sessões e teriam potencialmente travado para todos,

De qualquer forma, como você sugere na sua alteração, também acho melhor recriar o objeto. Então, talvez apenas armazenar a identificação e, a cada solicitação, extrair o objeto do banco de dados, seja melhor / mais seguro.