Discussion :

[arnolem]

Bonjour, je ne cherche pas de réponse technique mais plutot des retours d'experience.
Je touche à plein de languages et j'ai découvert la Programmation Orienté Objets sous php, mon soucis c'est que je ne vois pas trop comment l'utiliser, alors voici quelques pistes si vous avez envie d'en débattre avec moi :

1. Utilisez vous la POO en php pour vos sites internet ?
2. Quels sont les objets que vous définissez ? (user, group, mysql ...)
3. Comment stocker un objet d'une page à une autre ?
4. Que définissez vous dans une class user par exemple ?
5. Est il utile de stocker toutes les requetes possible dans une classe ?
   (GetName(), GetPassword(), UpdatePassword(), GetNbUsers() ...)
6. Il y a t'il une perte de performance d'inclure toutes les classes à chaque pages ou sont elle chargée uniquement lorsqu'une instance est créé ?
7. supprimé
8. Il y a t'il un interet à stocker des informations utilisateur dans un objet plutot que dans un cookie ou une variable session ?

Bon j'en ai d'autre mais je pense que c'est déja un bon début, les débat sont lancé, merci d'indiquer le numéro de la question si vous souhaiter y répondre directement

[hugo123]

Salut,
Ces questions ont l'air apparemment collés a une appli que tu as en tête. Je répondrais peut être à côté.
1. J'utilise effectivement la POO en php pour mes sites. Elle me permet de séparer l'application en couches. Mon but c'est de pouvoir en faire évoluer une sans modifier les autres lorsqu'il s'agit de couches techniques : Acces base, système de templates etc...
J'utilise aussi la POO pour réutiliser facilement des pattern connu (modèle MVC, modèle relationnel objet etc...) et des libraires (PEAR par exemple).
Pour moi le principal reste la séparation des couches et la réutisabilité.
2. Les objets vont dépendre de mon appli mais dans l'ensemble, je respecte le modèle MVC, j'ai des objets techniques, des services métiers, des objets permettant un mapping Objet-BDD etc...
3. Les sessions permettent de passer un objet d'une page a une autre.
4. Une classe user ? Ben tout dépend du user ^^
5. Un peu flou comme question. Oui il est possible de centraliser les requêtes dans une même classe. C'est d'ailleurs préférable au fait de les avoir disséminés partout dans le code.
6. La perte de performance est minime. Mais il est clair que je préfère inclure uniquement ce dont j'ai besoin au moment ou j'en ai besoin.
7. en double avec 3
8. C'est pas la même utilisation pour les 3 types des stockages. Ta session vont te permettre de garder l'état d'un client sur plusieurs pages. Ton cookie, des infos pour sa prochaine connexion et ton objet plutot des infos sur l'état du client sur la page en cours.

[Bebel]

1. Utilisez vous la POO en php pour vos sites internet ?
->Oui, cela fait quatre que je programme, et pour certains site cela est beaucoup plus simple. mais je ne fais pas tout avec des classes non plus cela depend du but du site.

2. Quels sont les objets que vous définissez ? (user, group, mysql ...)
->Un pour la gestion des bases, un pour la gestion du resultat
et apres c'est assez aleatoire

3. Comment stocker un objet d'une page à une autre ?
->En serializant

4. Que définissez vous dans une class user par exemple ?
->les attributs (nom,sexe,prenom,...) plus d'autre méthodes utiles

5. Est il utile de stocker toutes les requetes possible dans une classe ?
->Perso, j'utilise une super classe qui gere tout ca (sauf cas particulier) donc les requetes courantes ne sont definies que dans cette classe.

6. Il y a t'il une perte de performance d'inclure toutes les classes à chaque pages ou sont elle chargée uniquement lorsqu'une instance est créé ?
->le temps d'un include est assez rapide, donc j'inclus systematiquement les plus courantes, et les autres au besoin.

7. Comment stocker un objet d'une page à une autre ?
->idem que la 3

8.Il y a t'il un interet à stocker des informations utilisateur dans un objet plutot que dans un cookie ou une variable session ?
-> le cookie n'est pas quelque chose de fiable, si l'utilisateur l'interdit.
et ensuite session ou objet je pense que cela depend du point de vu.

Voila si ca peut t'aider

[jeff_!]

salut

1. oui ( je mis suis et je m'en pass plus)
2. template, config, acces au donnés,
3. les sessions
4. login, group, et la class personne(heritage ou composition)
5. non, plutot prefere un mapping objet / relationnel dans l'ideal, sinon fichier de conf(xml,ini,php)
6. utilisation d'autoload, la perte de perf ne doit aps etre sensible, bien qu'il est preferable d'inclure toutre les classes au debut
7. je l'ai deja vu cele la
8. tous de pend si c'est au cour d'une execution ou d'une page sur l autre(la de toutre facon tu n'a pas le chois coockie ou session)

vite fait pas trop de temps

[ePoX]

Salut,

1. Utilisez vous la POO en php pour vos sites internet ?
   Oui
   ___________________________________________________
2. Quels sont les objets que vous définissez ? (user, group, mysql ...)
   Come dit plus haut, cela dépend du contexte. Une analyse au préalable permet de faire le tri et d'y voir plus clair.
   ___________________________________________________
3. Comment stocker un objet d'une page à une autre ?
   Sa dépend de la vocation de l'objet, si il à besoin d'être persistent indépendamment de la session, un sgbd/R/O devra être utilisé.
   Après il peut exister certains objet qui n'existe que le temps d'une session. Donc la session pourra paraitre très approriée.
   ___________________________________________________
4. Que définissez vous dans une class user par exemple ?
   Sa dépend de l'analyse.
   ___________________________________________________
5. Est il utile de stocker toutes les requetes possible dans une classe ?
   (GetName(), GetPassword(), UpdatePassword(), GetNbUsers() ...)
   De ce que j'en comprend, c'est l'idée, la classe c'est un contexte qui de par nature regroupe les requetes en rapport avec ce contexte.
   ___________________________________________________
6. Il y a t'il une perte de performance d'inclure toutes les classes à chaque pages ou sont elle chargée uniquement lorsqu'une instance est créé ?
   Php est assez optimisé pour prendre en compte cela efficacement. C'est minime comme dis plus haut.
   ___________________________________________________
7. supprimé
   Ok.
   ___________________________________________________
8. Il y a t'il un interet à stocker des informations utilisateur dans un objet plutot que dans un cookie ou une variable session ?
   Rien à voir. Ton objet peut être stocké ou tu veux. Un fichier plat, un sgbd, un cookie, une session ect. C'est son problème que d'utiliser le bon gestionnaire de persistence. Lors de l'utilisation de l'objet, tu n'as pas à te précocuper de sa provenance.
   Il faut donc dissocier le moyen de stockage de l'utilisation de l'objet.
   (J'espère être clair, j'ai quelques doutes).

bbye

[arnolem]

merci pour en revenir à la question :
Est il utile de stocker toutes les requetes possible dans une classe ?

En fait j'avais commencé par faire un class USER
et j'avais ecris une fonction par requetes que je comptais utiliser.
par exemple :

• getId(name string)
• getName(id int)
• getSurName(id int)
• getIdGroup(id int)
• getEmail(id int)
• getCryptPassword(id int)
• UpdatePassword(id int,newPassword string)
• UpdateEmail(id int,newEmail string)
• BanUser(id int,state boolean)
• ActivUser(id int,state boolean)
• ...

Ensuite j'ai fais une class USERS :

• addUser(name string,email string,password string)
• delUser(id int)
• getNbUsers()
• ...

Et j'était parti por faire pareille avec un objet forum, topic, news, group ... afin de stocker toute mes requetes dans des fichiers de classes.

La ou je ne vois pas l'interet de se que je fais c'est que je crais une instance sur chaque page juste pour afficher des informations.
Pour afficher toutes les infos d'un utilisateur sur une page, il y a plusieurs requêtes alors qu'une seule pourrais ramener tout dans un tableau.
Voila un peu, je ne vous ai pas tout dis mais voila de quoi vous aider à m'aider (c'est marrant ça).

[Tipoun]

1. Oui, surtout pour les projets conséquents (jeu en ligne, site avec une base de données et qui tend à se développer)
2. Les classes de bases : une classe pour se connecter à la BD, une autre par page (news, photos...) et la classe template, pour les utilisateurs
3. Une session c'est parfait !! Ou alors les POST ou GET.
4. Nom, Prenom (toutes les infos sur lui), date de connexion, puis ensuite ça dépend du contenu du site
5. Je pense que cette méthode est exagérée : le nombre de requête sera très important pour juste sélectionner deux infos....
6. Il ne faut inclure que les classes que l'on se sert dans la page. Par contre dans index.php, j'inclu les classes contenant les constantes et la connection à la BD (sachant que presque chaque page les utilise)
7. supprimé
8. Un objet pourra être sauvegardé dans un BD ou un fichier et restituer facilement. La variable sesion est détruise lors de la déconnection et le cookie n'est pas assez sécurisé.

[arnolem]

si l'objet est enregistré dans la bd, je ne vois pas l'interet a part ceux que tu évoque car si je fais des objets c'est aussi pour limiter les acces à la bd alors si c'est pour en restocker dedans, c'est pas la peine.
Sinon mon début vous parait a coté ou non ? moi oui

[hugo123]

Le découpage est toujours problématique dans un cas comme celui ci. Parfois il peut être utile de se faire un petit diagramme de classe pour voir si on passe pas a coté d'un truc.
Mais le découpage que tu sembles indiquer a l'air cohérent pour un forum.
Quand tu parles du fait que tu crées une instance pour chaque page, cela parait logique a partir du moment ou tu réaffiches la même chose a chaque fois. Tu peux toutefois utiliser un système de cache qui conditionne l'instanciation (si mon cache est récent, je n'instancie pas).
Pour ce qui est des requêtes, il faut pas hésiter a faire des fonctions plus complexes que GetName etc... qui permettent de ramener plus d'infos d'un seul coup. Multiplier les requêtes serait en effet très pénalisant pour les performances. Par exemple un GetUserInfo qui renverrait un array.
Quoi qu'il en soit, s'attaquer a un forum, ca reste un sujet très complexe et très vaste ^^

[wamania]

Salut

J'approuve bien sur tout ce qui a été dit.
Par contre, je voudrais ajouter qu'une classe n'est pas juste un paquet de fonctions qu'on regroupe ensemble, mais bien la représentation d'une entité distincte et indépendante.
En d'autre terme, j'estime inutile de réaliser une classe user avec juste des méthodes pour effectuer de simple requete (plus proche de la BDD que du user), mais tres utile au contraire d'avoir une méthode GetUserInfo comme dit hugo123 qui est elle directement lié au user, indépendamment de l'origine des données.

Wamania

[bkill]

1. Utilisez vous la POO en php pour vos sites internet ?
   
   Oui. Tout dépend évidemment de la complexité et des fonctionnalités requises, mais les projets d'une assez bonne envergure ainsi que pour ceux dont les fonctionnalités vont pouvoir être réutilisées, j'utilise la POO.
2. Quels sont les objets que vous définissez ? (user, group, mysql ...)
   
   Ce genre d'objets, oui. Mais encore "news" (pour des affichages de news - fûté non? ), mailing pour des applis envoyants des mailings massifs, "sms" pour le meme genre d'appli etc etc
3. Comment stocker un objet d'une page à une autre ?
   
   Session / serialize
4. Que définissez vous dans une class user par exemple ?
   
   La, ca dépend déjà du php4 ou 5, avec l'ajout presqu'automatique des get / set... Sinon, de manière générale, des fonctions pour get/set les variables membres (pas d'accès direct, dans la mesure du possible), fonction de chargement des données d'un objet pour un id donné dans une DB, ... Et toutes les fonctions utiles résultant d'une analyse préalable de la fonctionnalité de l'objet
5. Est il utile de stocker toutes les requetes possible dans une classe ?
   (GetName(), GetPassword(), UpdatePassword(), GetNbUsers() ...)
   
   Aucun intérêt si l'utilité n'est pas là. Pour faire de la bonne POO, une analyse s'impose (UML, ...), et ca permet déjà de déterminer la majorité des fonctions nécessaires (et des requêtes indirectement, la/les requête(s) étant directement liées à l'utilité de la fonction.
6. Il y a t'il une perte de performance d'inclure toutes les classes à chaque pages ou sont elle chargée uniquement lorsqu'une instance est créé ?
   
   je pense que ca peut etre négligeable. Ceci dit, si l'objectif est l'optimisation à mort, la solution d'inclure uniquement là où c'est utile est tout de même plus appropriée.
7. supprimé
   
   
8. Il y a t'il un interet à stocker des informations utilisateur dans un objet plutot que dans un cookie ou une variable session ?
   
   Tout dépend de l'utilité de ces informations. puis pourquoi ne pas combiner plusieurs de ces possibilités? Genre stocker en session l'objet utilisateur? (si on a besoin sur plusieurs pages d'affilée d'afficher le nom, le prenom, et d'autres infos personnelles, plutot que de créer une var séparée pour chaque info)

[arnolem]

En fait je suis en train de faire un projet qui va débuter bientot et qui est fixé sur 5 ans, avec forum, sous-domaines, galerie photos ...
Donc je préfèrerais partir d'un bon pied.
Sinon en se qui concerne les méthodes, je ne stocke pas que des méthodes mais aussi une variable par information du style $username ; $city ...
Mais se n'est peut etre pas la bonne méthode, je vais revoir ça avec tous se qui m'a été dis et je vous redit ou je bloc
merci

[ePoX]

Pour afficher toutes les infos d'un utilisateur sur une page, il y a plusieurs requêtes alors qu'une seule pourrais ramener tout dans un tableau.

Oui, il faut essayer de penser un peu autrement pour faire des instanciations qui ne requiert pas 50 accès base.
En tout cas d'après mon expérience actuel, qui n'est pas encore très lourde, l'approche objet n'est pas une usine à performance de manière naturel et cela requiert de réfléchir à l'optimiation du code.

Ceci dit quand tu cites les méthodes (GetName(), GetPassword(), UpdatePassword(), GetNbUsers() ...) pour moi ce ne sont que des accesseurs, et il ne devrait pas avoir comme tache première d'aller lire l'information dans la base. Cette tache devrait être dédié à une autre méthode qui peuple l'objet de manière plus efficace.

si l'objet est enregistré dans la bd, je ne vois pas l'interet a part ceux que tu évoque car si je fais des objets c'est aussi pour limiter les acces à la bd
alors si c'est pour en restocker dedans, c'est pas la peine.

restocker dedans, quoi ? Les objets, le sgbd ? Je ne comprend pas trop personnellement.

bbye

[arnolem]

qu'entend tu par plus efficace, en fait je ne sais pas comment procèder c'est bien la le problème alors n'hésitez pas à me dire plus en précisions.
Sinon je disais que faire une requete, pour générer un objet puis stocker l'objet dans la bd ça n'a pas de sens pour moi.

[jeff_!]

en fait tous depand de la complexité de tes objets, si la construction de ton objet fait appel a 3 ou 4 autre objet qui sont font appel a des requete sur pluseiur table, peut etre qu'il est interessant de sauvegarder l'objet en session (fichier ou db)
le but est de minimiser les acces à la base
par example tu creer un objet groupe et quand tu le set, tu creer tout les objet user avec leur propriété et qaund tu fait un getQuelquechode tu va lire les propriété d'un objet user

[ePoX]

qu'entend tu par plus efficace, en fait je ne sais pas comment procèder c'est bien la le problème alors n'hésitez pas à me dire plus en précisions.
Sinon je disais que faire une requete, pour générer un objet puis stocker l'objet dans la bd ça n'a pas de sens pour moi.

Et pourtant l'interet de l'approche objet et de gagner en sens. Faire en sorte que ton code se rapproche du fonctionnel, et non pas du technique.
C'est aussi cela l'interet d'utiliser l'approche objet, pas seulement la ré utilisation comme on peut souvent le voir.

[davcha]

Et pourtant l'interet de l'approche objet et de gagner en sens. Faire en sorte que ton code se rapproche du fonctionnel, et non pas du technique.
C'est aussi cela l'interet d'utiliser l'approche objet, pas seulement la ré utilisation comme on peut souvent le voir.

Les deux -- à la fois le "code qui se rapproche du fonctionnement 'réel'" et la réutilisation -- se rejoignent assez souvent, je pense, puisque généralement, en structurant le problème sous forme d'objets, on sépare les différents métiers.

Sinon, je suis moi aussi assez intéressé par cette question de l'approche objet en php (c'est quelque chose dont j'ai l'habitude dans d'autres langages, mais en php, je suis un peu débutant de ce côté là).

[arnolem]

sinon pour la création des objets, c'est du générique ou c'est des véritables objets lié, je m'explique.
Dans mon cas, pour afficher le nom d'un utilisateur a partir de son id je faisait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$user = new user ;
$user->getNameById(23) ;

se que je veux dire c'est que mon user est générique

Faut il plutot faire un user défini, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$user23 = new user(23) ;
$user23-getName() ;

Je suis clair ?

[hugo123]

Si tu utilises la première solution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
$user = new user ;
$user->getNameById(23) ;

L'initialisation ne sert pas a grand chose puisque le constructeur n'a aucune info a setter.
Le getNameById va ramener une donnée pour un user défini.

Tout dépend de l'utilisation, parfois c'est bien, mais la plupart du temps on choisira la seconde solution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
$user23 = new user(23) ; // initialisation par peuplement de l'objet (recherche d'info en base)
$user23->getName() ; // le get ici va chercher des infos de l'objet, 
// par exemple le name mais ca aurait pu être autre chose 
// ramené lors de l'instanciation.

[Dinofly]

Je programme beaucoup en objet en PHP et j'essaie d'être le plus rigoureux possible. Seulement, je me heurte à un problème d'optimisation. En effet, si j'ai à récupérer une liste (qui peut être très longue) d'utilisateurs stockés en base par exemple, il est totalement exclu de les charger un à un comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
foreach( $aIdentifiants as $iId ) {
$aUsers = new User( $iId );
}

Sachant que le constructeur de User ira faire un SELECT dans la base.

Si j'ai 1000 utilisateurs à récupérer je vais lancer 1000 requêtes vers mon serveur SQL, c'est totalement délirant.

Donc je suis obligé de passer par des moyens détournés, du genre User::getUsersFromIdList( $aIdentifiants ) qui me créera autant d'utilisateurs avec une seule requête de type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$sql = "SELECT * FROM utilisateurs WHERE id IN (".implode(', ', $aIdentifiants).")"

Ca fonctionne, mais je n'aime pas cette solution.
En avez-vous d'autres ?