Session class design
Moderator: General Moderators
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
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.
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
Ahh yes I am in favor of that xDYou 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.
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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.
I should note that you can also save the whole object in the session as well.
(#10850)
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.ole wrote:Seriously I can't think of a logical reason why you would need more than one session.
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
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.ole wrote:So, it wouldn't make sense to keep that in a database?It would make sense to create a session for general data, and then another session that is specific to a registered user.
Is that general data specific to more than one user? Because if it is its not a session.
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.