Session class design

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

Abstraction is the name of the game, my friend. Let your class(es) worry about the specific interaciton and implementation. It should be as close as possible to a black box as far as your other code should be concerned. Why? Because you may discover down the road you want to change how the system interacts with php's session handling, or may choose to use some other solution.
User avatar
Luke
The Ninja Space Mod
Posts: 6424
Joined: Fri Aug 05, 2005 1:53 pm
Location: Paradise, CA

Post by Luke »

I understand and agree with that feyd, but were you responding to my question?
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

The Ninja Space Goat wrote:I understand and agree with that feyd, but were you responding to my question?
Yes, I was. You didn't have code posted at the time when I was creating it.
User avatar
Luke
The Ninja Space Mod
Posts: 6424
Joined: Fri Aug 05, 2005 1:53 pm
Location: Paradise, CA

Post by Luke »

that's what I figured (and that's why I asked :) )
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

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.
Ahh yes I am in favor of that xD

Ninja, I prefer first one, I try to avoid multidimension array structure such as that. Oh and use something like 'commit' instead of 'saveSession' I'd say.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

The difference is really whether you want or need a commit() method. Usually you can just write to $_SESSION or better inherit/composite a Session class and use its get/set methods. But if you have an object that needs to prepare data and only save it if successfully prepared then the commit() method would make sense.

I should note that you can also save the whole object in the session as well.
(#10850)
bg
Forum Contributor
Posts: 157
Joined: Fri Sep 12, 2003 11:01 am

Post by bg »

ole wrote:Seriously I can't think of a logical reason why you would need more than one session.
Say you have a website that is available to all but has additional functionality for registered users. Say you also need to store session data for all visitors to the website, and additional session data for logged in users. It would make sense to create a session for general data, and then another session that is specific to a registered user.
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

It would make sense to create a session for general data, and then another session that is specific to a registered user.
So, it wouldn't make sense to keep that in a database?

Is that general data specific to more than one user? Because if it is its not a session.
bg
Forum Contributor
Posts: 157
Joined: Fri Sep 12, 2003 11:01 am

Post by bg »

ole wrote:
It would make sense to create a session for general data, and then another session that is specific to a registered user.
So, it wouldn't make sense to keep that in a database?

Is that general data specific to more than one user? Because if it is its not a session.
Yes I realize how a session works. Anything that could be saved in a session could just as well be stored in a database. We have the session to store temporary data. There may be data common to an unprivileged user and a registered user that you would want to store, and there also may be data specific only to a registered user. When the user logs in, another session is created for data specific to that user. When a user logs out, that session is destroyed, making for easy clean up. There may also be times when the registered user session does not need to be serialized. If everything is stored in one session, then once its been unserialized all its contents are now globally available.

This is just one scenario where security would be a big issue. There is also some practicality there too. More often than not using more than one session is unecessary but there are logical reasons for doing so.
Post Reply