129 votos

PHP: Almacenar ' objetos ' dentro de los $_SESSION

Me di cuenta de que en realidad puede almacenar objetos en el $_SESSION y me parece bastante genial, porque cuando me salta a otra página todavía tengo mi objeto. Ahora, antes de empezar a usar este enfoque me gustaría saber si es realmente una buena idea o si hay riesgos potenciales involucrados.

Yo sé que si yo tenía un único punto de entrada yo no tendría que hacer eso, pero yo no estoy allí todavía, así que no tiene un punto de entrada único y realmente me gustaría mantener mi objeto, porque no quiero perder mi estado de ese modo. (Ahora también he leído que debo programa de apátridas sitios, pero no entiendo ese concepto aún).

Así que en resumen: Es aceptar para almacenar los objetos en la sesión, ¿hay algún problema con ella?


Edición:

Temporal resumen: Por ahora entiendo que es probablemente mejor para recrear el objeto, incluso si esto implica consultar la base de datos.

Más respuestas tal vez podría elaborar en ese aspecto un poco más!

93voto

shanusmagnus Puntos 1000

Sé que este tema es viejo, pero este problema sigue saliendo y no se ha dirigido a mi satisfacción:

Si deseas guardar objetos en $_SESSION, o reconstruir, todo trapo basado en los datos guardados en campos ocultos de formulario, o volver a consultar de la base de datos cada vez, usted está de acuerdo con el estado. HTTP apátridas (más o menos; pero véase OBTENER vs. PONER), pero casi todo lo que alguien que se preocupa de hacer con una aplicación web que requiere el estado para mantenerse en algún lugar. Actuando como empujando el estado en rincones y grietas cantidades a algún tipo de triunfo teórico está mal. El estado es el estado. Si usted utiliza el estado, se pierden las diversas técnicas de ventajas obtenidas al ser apátridas. Esto no es algo para perder el sueño a menos que usted sabe de antemano que usted debería estar perdiendo el sueño.

Estoy muy desconcertado por la bendición recibida por la "doble golpe" argumentos expuestos por Hank Gay. Es el OP de la construcción de un modelo distribuido y con equilibrio de carga sistema de comercio electrónico? Mi conjetura es que no; y voy a seguir postulan que registrar sus $clase de Usuario, o lo que sea, no lastimen a su servidor más allá de la reparación. Mi consejo: utilice técnicas que son sensibles a su aplicación. Objetos en $_SESSION están bien, sujeto a precauciones de sentido común. Si la aplicación de repente se convierte en algo que rivaliza con el de Amazon en el tráfico servido, tendrá que volver a adaptarse. Así es la vida.

87voto

cruizer Puntos 4821

vale tanto como cuando que se realiza la llamada session_start (), la definición/declaración de clase ya se ha encontrado por PHP. de lo contrario no sería capaz de deserializar el objeto desde el almacén de la sesión.

35voto

Hank Gay Puntos 36173

HTTP es un protocolo sin estado por una razón. Sesiones de soldadura de estado en HTTP. Como regla general, evite el uso de estado de la sesión.

ACTUALIZACIÓN: No existe el concepto de una sesión en la HTTP nivel; servidores de proporcionar esta dando al cliente un IDENTIFICADOR único y decirle al cliente que volver a enviarlo en cada solicitud. A continuación, el servidor utiliza el ID como clave en una gran tabla de hash de los objetos de Sesión. Cada vez que el servidor recibe una petición, consulta la información de la Sesión de su hashtable de los objetos de sesión basado en la IDENTIFICACIÓN de el cliente ha presentado con la solicitud. Todo este trabajo extra es un doble golpe en la escalabilidad (una gran razón HTTP apátridas).

  • Mala suerte: Se reduce el trabajo de un único servidor puede hacer.
  • Whammy Dos: Que sea más difícil de escalar, ya que ahora no sólo puede ruta una petición a cualquier servidor antiguo - que no todos tienen la misma sesión. Usted puede fijar todos los pedidos con un determinado IDENTIFICADOR de sesión en el servidor mismo. Eso no es fácil, y es un punto único de fallo (no para el sistema como un todo, pero para grandes trozos de sus usuarios). O, usted podría compartir la sesión de almacenamiento a través de todos los servidores del clúster, pero ahora tiene más complejidad: conectado a la red de la memoria, un independiente de sesión de servidor, etc.

En vista de todo eso, de la información más que poner en la sesión, la más grande es el impacto en el rendimiento (como Vinko puntos). También como Vinko puntos, si su objeto no es serializable, la sesión se portan mal. Así que, como regla general, evite poner más de lo estrictamente necesario en el período de sesiones.

@Vinko normalmente puede evitar que el servidor almacene el estado mediante la incorporación de los datos de seguimiento en la respuesta que usted envíe de nuevo y que el cliente vuelva a enviar, por ejemplo, el envío de los datos en un oculto de entrada. Si usted realmente necesidad del lado del servidor de seguimiento de estado, probablemente debería estar en su copia de almacén de datos.

(Vinko añade: PHP puede utilizar una base de datos para almacenar la información de la sesión, y que el cliente vuelva a enviar los datos cada vez que puede resolver los posibles problemas de escalabilidad, sino que se abre una gran lata de problemas de seguridad debe prestar atención a ahora que el cliente está en control de todo su estado)

13voto

Vinko Vrsalovic Puntos 116138
  • Objetos que no se puede serializar (o que contienen unserializable miembros) no saldrá de la $_SESSION como usted esperaría
  • Sesiones enormes poner una carga en el servidor (serializar y deserializar megas de estado cada vez que son costoso)

Aparte de eso no he visto sin problemas.

7voto

Greg Puntos 7391

En mi experiencia, es generalmente no vale la pena para nada más complicado que un StdClass con algunas propiedades. El costo de a siempre ha sido más que recrea desde una base de datos dado un identificador de sesión almacenada. Me parece bien, pero (como siempre), perfilado es la clave.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by: