Page 1 of 2
Storing an object in a session
Posted: Mon Nov 26, 2007 10:58 am
by someberry
I should imagine this is a very bad idea, but thought I would seek clarification here.
Has anyone ever used this in production which actually was a success, or is it such a bad idea that I should slap my friend for suggesting it? Sorry for the PHP4, don't have access to 5 at the moment.
Code: Select all
<?php
session_start();
class myClass {
var $_name;
function myClass() {
$this->_name = 'Foobar';
}
function getName() {
return $this->_name;
}
}
if (!isset($_SESSION['obj'])) {
$_SESSION['obj'] = new myClass();
header('Location: index.php'); exit();
}
echo 'My name is: ' . $_SESSION['obj']->getName();
Posted: Mon Nov 26, 2007 11:13 am
by Oren
Code: Select all
<?php
session_start();
class myClass {
var $_name;
function myClass() {
$this->_name = 'Foobar';
}
function getName() {
return $this->_name;
}
}
if (!isset($_SESSION['obj'])) {
$obj = serialize(new myClass());
$_SESSION['obj'] = $obj;
header('Location: index.php'); exit();
}
// index.php:
class myClass {
var $_name;
function myClass() {
$this->_name = 'Foobar';
}
function getName() {
return $this->_name;
}
}
session_start();
$obj = unserialize($_SESSION['obj']);
echo 'My name is: ' . $obj->getName();
Posted: Mon Nov 26, 2007 11:18 am
by aaronhall
I started doing this with singleton objects that represent state, and it fits in beautifully with my MVC applications. I believe the serialization step is only necessary if you call session_start before loading your class definitions, and redundant if you don't.
Posted: Mon Nov 26, 2007 11:19 am
by someberry
Hi Oren
My code works fine (on PHP4, don't know if PHP5 you need to (un)serialize). I was also aware that one could (un)serialize.
My main concern was whether or not this is a feasible method, or whether it is a big no-no for x, y, and z reasons.
Thanks

Posted: Mon Nov 26, 2007 11:30 am
by John Cartwright
Well I think it is obvious that there will be overhead from having to persist objects in sessions and serializing/unserializing, but I would probably avoid its usage simply because it smells of a poor design. I would probably prefer storing the data and not the object itself in the session, then simply repopulate it on the next request.
I don't think it is a "big no-no", but I would do so with caution.
I think the bigger question is, why do you want to store an object in the session?
Posted: Mon Nov 26, 2007 11:33 am
by someberry
Jcart wrote:I think the bigger question is, why do you want to store an object in the session?
State. Only means calling the database once to get all the information instead of once per page load.
I initially thought it seemed a bit of a poor design method, but thinking about it I tihnk it could suit, as Aaron stated, a singleton. I am warming to the idea.
Posted: Mon Nov 26, 2007 11:37 am
by John Cartwright
someberry wrote:Jcart wrote:I think the bigger question is, why do you want to store an object in the session?
State. Only means calling the database once to get all the information instead of once per page load.
I initially thought it seemed a bit of a poor design method, but thinking about it I tihnk it could suit, as Aaron stated, a singleton. I am warming to the idea.
Jcart wrote:I would probably prefer storing the data and not the object itself in the session, then simply repopulate it on the next request.
I hope this doesn't turn into a state vs. stateless debate again.
Posted: Mon Nov 26, 2007 11:43 am
by someberry
Jcart wrote:I hope this doesn't turn into a state vs. stateless debate again.
I'm not here to debate, just to find out whether or not I should turn back from the dark/light side that is storing classes in sessions

Posted: Mon Nov 26, 2007 11:54 am
by John Cartwright
I probably should be bit a bit more clear. As for storing the object itself within the session, it really comes down to if you are willing to accept the overhead.
I initially thought it seemed a bit of a poor design method, but thinking about it I tihnk it could suit, as Aaron stated, a singleton. I am warming to the idea.
Arguably, singletons can be considered a poor design choice as they are hard to test and create a direct dependency with the singleton. If you are going that route, I would suggest tucking your objects inside a registry.
Posted: Mon Nov 26, 2007 11:56 am
by Oren
someberry wrote:I was also aware that one could (un)serialize.
It's not "could", it's "must". You must do this if you want to pass the object in a session to the next page.
someberry wrote:My main concern was whether or not this is a feasible method, or whether it is a big no-no for x, y, and z reasons.
Answer:
Jcart wrote:I don't think it is a "big no-no", but I would do so with caution.
Posted: Mon Nov 26, 2007 12:01 pm
by feyd
Serialization is not required. Sessions automatically serialize their stored data. Doing a serialization for it simply increases (often) the storage requirements, but also makes you do more work on the receiving end. As long as the class is known when session_start() is called, the object will be unserialized for you. If it is not, you will get a notice/warning/error.
Posted: Mon Nov 26, 2007 12:08 pm
by Oren
Last time I checked, this wasn't the case. Are you sure?
Posted: Mon Nov 26, 2007 12:14 pm
by John Cartwright
Oren wrote:Last time I checked, this wasn't the case. Are you sure?
Yup.
Posted: Mon Nov 26, 2007 12:15 pm
by Kieran Huggins
I wouldn't feel all that guilty storing objects in the session.
Just remember to define custom objects BEFORE you start the session. I think Oren was essentially saying the same thing, but I thought I'd point it out.
Posted: Mon Nov 26, 2007 12:20 pm
by Oren
Well now I'm really confused
I've just checked and it seems to work without serialize()/unserialize() at all.
I'm almost sure that in earlier versions of php you had to do it yourself
And it also seems that you can even define it AFTER session_start() is called.