Session class design
Moderator: General Moderators
Session class design
It makes sense to me to create my session class as a singleton, as no matter what application I port it into, sessions are more than likely going to be similar (since it will basically just be a wrapper for php's already developed session functions). What do y'all think? Any reason not to [made-up word]singletonize[/made-up word] it?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
If your session class uses $_SESSION internally then it can't help but be a Singleton. A separate question is whether you might have multiple classes that access that data source -- the answer for me is yes. If your session supports namespaces then multiple objects accessing the session is a cool feature.
(#10850)
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Modular systems where you want to be able to transparently store variables in one module without worrying if the name clashes with a varaible in another module. I partition my session data on a per-module basis.The Ninja Space Goat wrote:I have heard about having multiple sessions, but haven't been able to think of a situation where that would be needed... examples?
Making the session class a singleton won't really help much since $_SESSION is $_SESSION wherever you are.
My session class is registered and it stays in $this->session all the time so I can do:
Code: Select all
$foo = $this->session->get('foo');EDIT | The reason I access it in $this->session rather than explicitly taking it from the registry is that I use an extended registry for convenience and readable code
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Well if your session support namespaces liike this:The Ninja Space Goat wrote:I have heard about having multiple sessions, but haven't been able to think of a situation where that would be needed... examples?
Code: Select all
class Session {
var $namespace = 'Session';
function __construct ($namespace) {
if ($namespace) {
$this->namespace = $namespace;
}
}
function set ($name, $value) {
if ($name) {
$_SESSION[$this->namespace][$name] = $value;
}
}
function get ($name) {
if ($name) {
return $_SESSION[$this->namespace][$name];
}
}
}Code: Select all
$user = new Session('User');
class PagerSession extends Session {
function __construct () {
$this->namespace = 'Pager';
}
}
$pager = new Pager(new PagerSession());(#10850)
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
I've considered defining the namespace like that before arborint. I may modify the way my stuff works to allow new instances to be spurred off in a new namespace, each namespaced themselves. At the moment, the session class looks what module it's currently being used in by itself. I guess that's kinda unclean in a way and should be handled externally.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
The nice thing about namespaced session is that you get the code reuse of a single Session class but some guarantee of not trampling on each others data. I see it as exactly the same as dividing databases into tables -- to a connection object you pass the table name -- same data store, different record/class structure.
(#10850)
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
Seriously I can't think of a logical reason why you would need more than one session. You may want to be able to store/namespace different types of data separately then you have assoc arrays for that. I am write that you can use arrays as values for $_SESSION keys? If you can then you can store structured/organised data but they would still be all be part of the same session.
Thinking about multiple sessions just seems to make things very complex and I something I'd avoid. Multiple sessions implies to me that you application would be handling two or more users' sessions at once. Perhaps you could have some user's permissions (stored in their session) dependent on the contents of an administrator's session but PHP doesn't do that natively and you would obviously use a database to achieve such a thing.
Thinking about multiple sessions just seems to make things very complex and I something I'd avoid. Multiple sessions implies to me that you application would be handling two or more users' sessions at once. Perhaps you could have some user's permissions (stored in their session) dependent on the contents of an administrator's session but PHP doesn't do that natively and you would obviously use a database to achieve such a thing.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
You don't need more than one session (and in fact it would be a bit of work to create two in PHP). I don't think anyone was suggesting that.
But it does make sense to have multiple Gateway objects to the session data store. Just like with any data store you want to segregate data. With the filesystem it is directories and files, with a database it is databases and tables. This common two level organization is very common: a general container (directory/database) that hold specific containers (files/ables) that contain specifically structured data. If you treat the session the same it is then easy to create objects that hold specific data structures and save then in their own namespace.
But it does make sense to have multiple Gateway objects to the session data store. Just like with any data store you want to segregate data. With the filesystem it is directories and files, with a database it is databases and tables. This common two level organization is very common: a general container (directory/database) that hold specific containers (files/ables) that contain specifically structured data. If you treat the session the same it is then easy to create objects that hold specific data structures and save then in their own namespace.
(#10850)
- AKA Panama Jack
- Forum Regular
- Posts: 878
- Joined: Mon Nov 14, 2005 4:21 pm
So... moving on... Does it make sense to make different classes (for each type of session) (same interface) that are basically just associative array wrappers, and then once all logic is applied, save the array to the session, or would it make more sense to work with the session variables directly?
First one:
Or second one:
First one:
Code: Select all
class ObjectSessionRegistry implements SessionRegistry(){
function get($name){
return $this->values[$name];
}
function set($name, $value){
$this->values[$name] = $value;
}
function saveSession(){
$_SESSION[$this->namespace] = $this->values;
}
}Code: Select all
class ObjectSessionRegistry implements SessionRegistry(){
function get($name){
return $_SESSION[$this->namespace] [$name];
}
function set($name, $value){
$_SESSION[$this->namespace] [$name] = $value;
}
function saveSession(){
= $this->values;
}
}