Session

Session - PHP - Programmation

Marsh Posté le 14-03-2005 à 23:55:40    

Bonsoir,  
 
Je me suis fait une classe auth qui permet sur chaque page de vérifier si l'utilisateur est authentifié ou non.  
class auth
 - login
 - passwd
 - nom
 - prénom
 
Je me suis également fait une classe client, que j'utilise lorsqu'une personne souhaite créer ou éditer un compte.  
class client
 - adresse
 - CP
 - ville
 - pays
 - etc...
 
 
Je me sers des sessions pour mémoriser ces 2 classes (auth sur toutes les pages, client sur certaines pages uniquement).  
 
 
Je suis en train de me demander si je ne ferai pas mieux de les regrouper en une seule et unique classe car j'ai des attributs à "cheval" (besoin du login et du mot de passe de auth pour une inscription par exemple). Le souci, c'est que la classe auth contient 5 attributs tandis que la classe client environ 15.  
 
Est-ce genant de trimballer un objet d'une vingtaine d'attributs en session sur toutes les pages, ou est-ce que le fait que ce soit coté serveur fait que ce n'est pas un problème ?  
 
Merci d'avance

Reply

Marsh Posté le 14-03-2005 à 23:55:40   

Reply

Marsh Posté le 15-03-2005 à 08:08:02    

Etant donne que c'est cote serveur c'est pas vraiment un probleme, neanmoins ce n'est pas parceque c'est sur le serveur qu'il faut en abuser.
 
En effet, php se "termine" a chaque "fin de page". Donc il doit sauver les donnees dans la session car il ne peut pas les garder en memoire. Ce qui veut dire que par la suite, pour retrouver les donees, il va devoir les relire depuis le disque. Donc a la prochaine page, lorsque php va se "relancer" il va devoir re instancier ta classe. Bien que ce ne soit pas trop lourd, c'est lourd quand meme.
 
Donc faut eviter de stocker tout et n'importe quoi dans les sessions.
 
Les veritable question, est, as-tu reelement besoin de stocker ta classe dans la session ?
 
L'inscription, en theorie n'a lieu qu'une seule fois, et sur une seule page.
Tu fais remplir un formulaire au visiteur puis une fois que ce formulaire est envoye et que tu la verifie tu enregistre le client. Tu peux creer ta classe client au moment ou tu recois les donees de la part du formulaire. Mais je ne vois pas pourquoi tu dois absolument stocker cette classe dans les sessions (a moins que tu es decoupe le processus de creation d'un compte en plusieurs etapes).

Reply

Marsh Posté le 15-03-2005 à 14:18:59    

un simple ID comme variable de session ça suffit po...? :??:

Reply

Marsh Posté le 15-03-2005 à 14:26:03    

lkolrn a écrit :

un simple ID comme variable de session ça suffit po...? :??:


 
ça dépend si ça te coute cher de tout re-récupérer ou pas![:dawa]


---------------
Can't buy what I want because it's free -
Reply

Marsh Posté le 15-03-2005 à 17:02:56    

Je suis tout à fait d'accord avec toi cerel.
Le souci, c'est que par exemple je n'ai pas le nom dans la class client (présent dans la classe auth) du coup ca me forcerait à le mettre également dans la class client pour que celle-ci puisse gérer la création de compte seule (idem pour prenom etc) et je ne suis pas sur que d'un point de vue conception objet ce soit super propre d'avoir des attributs dupliqués en entre 2 classes.


Message édité par concombrinou le 15-03-2005 à 17:03:43
Reply

Marsh Posté le 15-03-2005 à 17:14:21    

Atta, ton problème est double et inexistant à la fois...
 
Visiblement tu t'emmèles les pinceaux dans la conception en effet... Fais tes classes de manière logique dans ton système: un client est aussi défini par son nom, donc cet attribut doit apparaître dans ta classe 'client'.
 
ps: tu n'es po obligé de coller à ta base de données, il y a plusieurs méthodes pour faire ses classes, qui correspondent à plusieurs usages...

Reply

Marsh Posté le 15-03-2005 à 17:22:23    

Pour la classe client je suis tout à fait d'accord que le nom et le prénom doivent en être des attributs.
 
C'est pour la classe auth que je suis plus ennuyé, puis-je mettre des attributs déjà existants dans la classe client ou est-ce que ce n'est pas propre et dans ce cas là, je dois trouver autre chose.
 
(La raison pour laquelle j'avais mis le nom et le prénom dans la classe auth, c'est parce que je les affiche sur toutes les pages)

Reply

Marsh Posté le 15-03-2005 à 17:50:13    

Sémantiquement parlant, tu ne dois po mettre un attribut dans 2 classes différentes qui désigne le même paramètre réel... Car pour ça on a la dérivation, ou l'héritage
 
 
Après cette règle n'est po intransgressible, tu peux créer 2 classes pour 2 usages différents et avoir des attributs en commun, le truc c'est que tu sépares bien en 2 pour avoir une idée claire de ce que tu fais... [:airforceone]
Seulement ça peut engendrer d'autres contraintes, comme ici au niveau de l'encombrement mémoire...


Message édité par lkolrn le 15-03-2005 à 18:06:23
Reply

Marsh Posté le 15-03-2005 à 17:57:37    

Je pense que je vais dupliquer les champs puisque le role des 2 classes est bien séparé.
 
classe auth: permet à une personne de s'authentifier et d'afficher son nom sur toutes les pages.
 
classe client: permet de créer ou éditer son compte.
 
Meme si ce n'est pas la méthode la plus optimisée (attributs doublons) c'est celle qui me parait la plus propre.

Reply

Marsh Posté le 15-03-2005 à 18:08:40    

Ca se tient! ;)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed