Vous, PHP et POO

[Quarky]

Voilà une petite question que je me posais ...

Pour ceux ne connaisant pas la chose, POO signifie "Programmation Orientée Objet". Voilà l'article de Wikipedia pour éclairer votre lanterne.

Pour info j'ai répondu "Oui, toujours".

[windu.2b]

2 votes (dont le tien?) et 100% à fond pour la POO

[LukeSkyPator]

J'ai répondu oui bien sûr, même si PHP n'a malheureusement encore aucune optimiation pour l'objet vu qu'il n'est pas nativement objet :'(

LSP, le manchot duke

[ZyriK]

Perso, non.

J'en utilise jamais et j'ai jamais fait de choses suffisament complexe pour en avoir besoin. (en php précisons)

Faut savoir aussi que l'objet a été adapté au php ...

[tsubasaleguedin]

J'ai mis parfois, car la POO n'est pas une solution miracle pour tous les problemes, dans certains cas il est plus leger/secure de ne pas faire de poo.

[Cubic-Design]

Perso j'ai beaucoup fait de POO en java (en même un peu obligé hein ;p) mais en PHP j'en fais pas car je programme de petit truc et même pour des back office j'avoue que la POO me prends la tête plus qu'autre chose

[ZyriK]

J'ai fait un CMS complet et j'ai pas eu besoin de POO ^^

Je précise que j'utilise plein de fonctions, mais jamais en classes.

[Cubic-Design]

Je trouve que l'intêret de la POO avec PHP c'est les applications en ligne, sinon ça va plus vite de faire du PHP simple (avec des fontions pour alléger un peu)

[LukeSkyPator]

Sauf pour du backend. Si tu fais pas de classes, ton code ressemble bien souvent à rien et tu te prives de bien des optimisations en terme d'accès en base

LSP, le manchot qui se dépêche de taper

[ingeni]

J'ai utilisé la POO en php pour encapsuler les appels aux BDD. Un eclasse pour créer la connexion, faire les requetes... Pour la fermeture, une méthode est appelée automatiquement à la fin du script et ferme la connexion sans que l'on ait rien à faire de ce coté....

[LukeSkyPator]

Hé hé. Vive PDO

LSP, le manchot au contexte qui démarre pas

[Cubic-Design]

J'ai utilisé la POO en php pour encapsuler les appels aux BDD. Un eclasse pour créer la connexion, faire les requetes... Pour la fermeture, une méthode est appelée automatiquement à la fin du script et ferme la connexion sans que l'on ait rien à faire de ce coté....

Heu dit comme ça ça ressemble pas trop à de la POO en tout cas c'est quasiment aussi faisable juste avec des fonctions à part pour l'encapsulation

[ZyriK]

Perso, dans mon CMS, j'ouvre la connexion au début avec un include (connect.php qui contient la connexion à la BDD)

J'appel au fur et à mesure de l'affichage de la page une fonction qui fait le café (tu lui donne la requête et elle fait le reste)

Et à la fin de la page, un mysql_close();

C'est sans POO et je suis certain qu'avec, c'est pas plus optimisé.

[Nuilok]

Moi j'ai mis parfois: pour des sites simples il n'y en a pas vraiment besoin en règle générale. En ce qui concerne les fonctions de gestion aux bases de données j'avais écrit une librairie de fonctions que j'ai récemment transformé en classe. Pas de pertes de performances visibles (le passage à PHP5 a été salutaire pour l'objet je trouve) et des fonctionnalités de débuggages plutôt intéressantes. Par exemple je peux activer le log automatique de toutes les requêtes d'un site: ça me permet de voir les requêtes les plus utilisées et de repérer celles qui ont intérêt à être optimisé le cas échéant.

Pour le reste, je n'utilise l'objet que pour écrire des classes d'accès aux données pour des applications web conséquentes. Lorsque des dizaines d'entités avec chacune des relations particulières avec d'autres objets commencent à envahir ma base de données je suis bien content d'écrire ces classes une bonne fois pour toute. Ça a trois avantages: premièrement, si on ajoute les nouvelles fonctionnalités de MySQL ça permet d'avoir une bonne intégrité de la base (depuis InnoDB en 3.23.xx on avait les contraintes de clefs étrangères, mais avec MySQL5 on peut enfin ajouter des procédures stockées et des triggers, ça commence à avoir une bonne tête). Deuxièmement, lorsque vous avez plusieurs personnes qui travaillent sur un projet web conséquent, on peut laisser quelques personnes bosser sur le moteur (classes d'accès aux données et de manipulation de la navigation), et laisser les autres travailler sur les fonctionnalités du site proprement dit sans qu'ils aient à se préoccuper de la réelle organisation de la base de données. Enfin, ça sert aussi quand vous voulez faire évoluer un site. Par exemple je me suis fait un site où je rentre toutes mes critiques des restaurants que je visite: les objets restent toujours les mêmes d'une version à l'autre (des restaurants, des avis, des notes), mais si je change l'organisation des données, je fais évoluer mes classes et le reste du site ne bouge que très peu. D'un autre côté si je change le site, je n'ai pas à retoucher aux sus-dites classes.

L'un dans l'autre j'utilise la POO quand elle peut me donner une certaine tranquillité d'esprit...

[RaphAstronome]

Perso, dans mon CMS, j'ouvre la connexion au début avec un include (connect.php qui contient la connexion à la BDD)

Et à la fin de la page, un mysql_close();

Faut pas faire comme ça, le temps entre la connexion et la déconnexion doit être le plus court possible, ex :

mysql_connect("host", "login", "pass");
mysql_selectdb("madb");
mysql_query("UPDATE pages SET Visites=Visites+1 WHERE ID='265'");
$page = mysql_query("SELECT titre, texte FROM pages WHERE ID='265'");
$docs = mysql_query("SELECT titre FROM pages WHERE Chapitre='2'");
mysql_close(); // il est inutile de laisser la connection ouverte

$page = mysql_fetch_array($page); // 1 seule entrée on peut l'écraser
echo "<h1>".$page['titre']."</h1>".$page['texte'];

echo "<div class='menu'>";
while ($val = mysql_fetch_array($docs)) {
 echo "<div class='selpage'>".$page['titre']."</div>";
}
echo "</div>";

(code pas vérifié)

[ZyriK]

Donc alors vaut mieux faire tout le temps des connexions/déconnexions plusieures fois plutot qu'on longue connexion ?

[windu.2b]

Donc alors vaut mieux faire tout le temps des connexions/déconnexions plusieures fois plutot qu'on longue connexion ?

Je ne pense pas... La connexion est une étape "lourde" (bon, pas tant que ça pour un humain, mais faut se mettre à l'échelle)! Ouvrir/fermer sans arrêt une connexion, ça ralentit d'autant le script (encore plus si le SGBDR n'est pas local, car dans ce cas il y a dialogue sur le réseau avec tout ce que cela entraîne).

La solution idéale serait d'ouvrir, lancer toutes les requêtes, fermer puis traiter les résultats avec le PHP. Sauf que c'est pas forcément faisable, et surtout ça nécessiterait d'extraire une partie du code de chaque classe et de le placer en tout début de l'exécution du script PHP...

[Nuilok]

C'est clairement un gouffre de performance dans un script que de déconnecter / reconnecter sans cesse (j'ai déjà vu des applis qui s'amusaient à en faire dans des boucles...). Par contre, je pense que quand on conçoit un nouveau site ou une nouvelle application web, il est assez facile de découpler la partie extraction des données, des traitements et de l'affichage proprements dits. Quand on fait des mises à jour, on ne peut pas toujours faire ce qu'on veut mais dans le cas contraire pourquoi s'en priver? Évidemment, il peut y avoir de menus traitements PHP qui s'intercallent dans la partie extraction, afin de restreindre la quantité d'informations que l'on extrait de la base (rule of thumb: si une information n'est pas utilisée sur une page, elle ne doit pas se retrouver dans les résultats des requêtes...) mais dès qu'on s'attaque à l'affichage, c'est qu'on sait ce qu'on veut, donc les accès à la base n'ont plus rien à faire là: sinon, une nouvelle réflexion sur la conception de la portion de code s'avère le plus souvent salutaire.

[Shinuza]

C'est ce qu'on apelle la sépartion des couches

Personellement je programme beaucoup en objet, mais pas en php, php et la poo c'est une grosse blague intersidérale.

[ZyriK]

Finalement c'est pas si mal ce que je fait ^^

La connexion à la base se fait du début de l'execution jusqu'a la fin, sachant que la page met environ 200 ms à se charger avec un bonne connexion internet, c'est pas si long ...

[Nuilok]

Finalement c'est pas si mal ce que je fait ^^

La connexion à la base se fait du début de l'execution jusqu'a la fin, sachant que la page met environ 200 ms à se charger avec un bonne connexion internet, c'est pas si long ...

Miiiip! Mauvaise réponse. Nan, j'rigole, pas tout à fait, mais ça mérite quelques détails je pense. Une petite rectification d'abord: le temps de calcul de ta page sur le serveur dépend assez peu de la connexion internet des clients. Ensuite, tout dépend de l'audience et du futur de ton site/application. Si une personne vient se connecter de temps en temps et que ta page prend 200 ms pour s'exécuter sur le serveur alors ça va gêner personne. Imagine maintenant qu'il y ait en permanence 5 ou 6 personnes qui effectuent des requêtes en simultanée? Multiplie ce chiffre par deux, trois, dix... cent en fonction de la popularité croissante de ton site, ou du nombre d'utilisateurs de ton application en intranet et que ce passe-t-il? Ben tu commences à recevoir des mails avec des gens qui te disent: Pourquoi est-ce que votre site affiche Connexion impossible à la base de données une fois sur deux?. Et oui, le nombre de connexions simultanées à une base de données est souvent limitée. Souvent à 1, parfois jusqu'à 5, rarement plus. Conséquence: laisser ouvert une connexion à la base alors que l'on n'en a plus besoin devient gênant dès lors que la probabilité qu'un autre visiteur en ait besoin en même temps devient mesurable. Si on ajoute à ça les divers timeout qui parsèment le chemin d'un serveur à un navigateur client, et tu peux avoir des visiteurs qui attendent 30s avant de voir un message d'erreur s'afficher.

C'est ce qu'on apelle la sépartion des couches icon_mrgreen.gif

Ben j'allais pas non plus me mettre à déblatérer sur les design pattern, et les MVC: j'ai préféré faire une explication "en français" plutôt qu'en terminologie (potentiellement) barbare

[...]php et la poo c'est une grosse blague intersidérale.

Ça s'est beaucoup amélioré avec PHP5: les performances sont meilleures qu'avant (il n'y a qu'à voir les moteurs MVC qui fleurissent dans pas mal d'applications PHP conséquentes sans overhead mesurable), et les fonctionnalités minimales sont là pour permettre de coder proprement en objet si l'on en a besoin. Se forcer à l'utiliser à toutes les sauces est clairement une mauvaise pratique. Mais le mettre systématiquement de côté sans y accorder une seule once d'attention? Mmm, je ne m'y risquerai personnellement pas. Si ça peut réduire mes cycles de maintenance, centraliser les processus complexes, m'aider encore plus à séparer les couches, pourquoi hésiter?

[windu.2b]

Finalement c'est pas si mal ce que je fait ^^

La connexion à la base se fait du début de l'execution jusqu'a la fin, sachant que la page met environ 200 ms à se charger avec un bonne connexion internet, c'est pas si long ...

Le temps de génération de la page (200ms dans ton cas) n'a strictement rien à voir avec le débit de ta connexion Internet! Tu pourrais surfer avec un 56k, la page mettrait autant de temps à se générer... Par contre, le débit influe sur le chargement, ça c'est évident.

Et je trouve que 200ms c'est déjà beaucoup! Certes, ça dépend de la charge du serveur et de laa complexité de la page...

[RaphAstronome]

ZyriK > Pour ce qui est des connexion / déconnexion il vaut mieux en avoir une seule mais il faut tout ratrouper et la plupart du temps on peut faire des pages qui n'ont que des "mysql_" entre la connexion et la déconnexion.

[ZyriK]

J'ai dit 200 ms mais j'ai pas vraiment vérifié ...

Comme dit dans la page précédente alors le truc à faire, POO ou pas, on se connecte, on récupère tout ce qu'on a besoin et on se déconnecte. Et après on se démerde pour afficher toutes ces infos au fur et à mesure du déroulement de la page.

Dans le cas d'un CMS c'est quasi impossible, enfin je pense. On a des choses à charger au début (genre infos sur l'utilisateur, sur le thème qu'il utilise ... etc) mais ensuite, en fonction du module dans lequel on est, on a d'autres choses à charger. Je précise que les chargements en début de page sont toujours les mêmes, contrairement à ceux dans les différents modules. Comment centraliser les accès à la base de données dans ce cas la ?

[Nuilok]

Ce n'est pas le CMS qui pose problème, mais bien l'architecture du CMS. En exagérant un peu, et sans y avoir trop pensé (je n'ai jamais écrit de CMS), on peut imaginer ça:

• chaque module est un objet qui contient une méthode de récupération des données, une méthode de traitement et une méthode d'affichage
  
• quand l'utilisateur veut afficher une page, le fichier principal (on va dire index.php) va ouvrir une connexion à la base puis va chercher les infos de base (infos utilisateurs, etc.) ainsi que la liste des modules de la page courante
  
• on boucle ensuite sur chacun de ces modules et on exécute la méthode de récupération des données
  
• puis on ferme la connexion à la base de données
  
• on boucle à nouveau sur les modules pour exécuter cette fois-ci les traitements
  
• on commence à afficher la page et quand le template courant rencontre une demande d'affichage de modules on exécute la méthode d'affichage du module
  

Donc, c'est toujours possible, mais il faut architecturer le CMS autour de ce concept et pas le contraire. Et dans un cas comme celui-ci, on peut soit jongler avec des includes et des librairies de fonctions, soit alléger un peu le tout en utilisant la POO.