+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : POO et DB (/showthread.php?tid=4598)
RE: POO et DB - Kihmé - 13-03-2010
je te remercie, je vais partir là dessus, car mes recherches avec "mapping object relationnal" n'apportent que du théorique
RE: POO et DB - Sephi-Chan - 13-03-2010
Pourtant, PHP dispose de plusieurs ORM. Il paraît que Doctrine est très bien.
Comme d'habitude, je ne peux que conseiller d'utiliser ce genre d'outils, afin de ne pas vous embêter à réinventer une roue qui tournera moins bien.
Sephi-Chan
RE: POO et DB - Kihmé - 14-03-2010
ouai je sais bien, mais voulant maitriser entièrement le sujet j'ai décidé de laisser les tools de côté
RE: POO et DB - Sephi-Chan - 14-03-2010
(14-03-2010, 01:50 AM)Kihmé a écrit : ouai je sais bien, mais voulant maitriser entièrement le sujet j'ai décidé de laisser les tools de côté
Le didactique s'entend très mal avec la qualité : tu vas devoir choisir.
Pourquoi ne pas utiliser un outil et se forcer à le comprendre ? Ce sera certainement plus didactique que de réinventer une roue branlante.
De plus, tu dis avoir un bon niveau technique, lire le code de Doctrine (par exemple) devrait être à ta portée.
Enfin, la décision t'appartient, mais tu n'es pas le premier (ni le dernier…) à croire que tu ne peux maîtriser que ce qui est de toi. C'est faux, bien sûr.
Sephi-Chan
RE: POO et DB - Anthor - 14-03-2010
Doctrine est très bien, en plus bientôt il prendra la place de Zend_Db en natif ! Miam
RE: POO et DB - Kihmé - 29-03-2010
(14-03-2010, 12:24 PM)Sephi-Chan a écrit :(14-03-2010, 01:50 AM)Kihmé a écrit : ouai je sais bien, mais voulant maitriser entièrement le sujet j'ai décidé de laisser les tools de côté
Le didactique s'entend très mal avec la qualité : tu vas devoir choisir.
Pourquoi ne pas utiliser un outil et se forcer à le comprendre ? Ce sera certainement plus didactique que de réinventer une roue branlante.
De plus, tu dis avoir un bon niveau technique, lire le code de Doctrine (par exemple) devrait être à ta portée.
Enfin, la décision t'appartient, mais tu n'es pas le premier (ni le dernier…) à croire que tu ne peux maîtriser que ce qui est de toi. C'est faux, bien sûr.
Sephi-Chan
Je crois que je vais me laisser convaincre, j'ai de moins en moins de temps pour le projet que je dois bientôt rendre et je suis toujours bloqué par le mapping. Je pense que je vais me laisser séduire par doctrine. Je suis actuellement en train de lire leur site web. Si vous avez des petits conseils ou des feedback à me donner avant que je me lance, je suis preneur.
RE: POO et DB - Kihmé - 17-04-2010
J'étais en train de regarder comment tu avais fait ta classe de connexion NicoMSEvent : t_DB.
Je ne comprend pas trop pourquoi ton attribut $_instance est en protected static.
J'aurais justement eu la tendance à le mettre en publique pour être sur de pouvoir y accéder en provenance de chacune de mes classes ayant besoin d'aller chercher des données dans ma bdd.
Ca sous entend que tu toutes tes classes (par exemple User, product etc...) sont des classes héritant de t_db?
Parce que là j'ai mes classes comme dans une application objet classique et je commençais à visualiser une classe de connexion que j'aurais mit en publique, comme ça je n'aurais pas eu besoin de la relier aux autres classes et j'aurais pu appeler ma fonction de connexion sans m'inquiéter de savoir où je suis. Mais apparemment ça ne ressemble pas à ce que tu as fais.
RE: POO et DB - Anthor - 17-04-2010
Parce que c'est un singleton, et on n'utilise pas directement l'objet.
Sinon inutile de placer une instance.
C'est aussi pour cette raison que le constructeur est privé.
RE: POO et DB - Kihmé - 17-04-2010
mais oui je suis bête, on appelle la méthode get pas l'attribut...
Un cherchant à propos de singleton j'ai bien compris son utilité.
Par exemple dans le cas d'une application client serveur, où le client contient le code sur un poste et la bdd est sur un serveur distant, on va avoir un client qui se créé son instanciation de la connexion qu'une seule fois, donc jusque là le singleton nous permet d'avoir une seule et unique instanciation de connexion par client.
Mais dans le cas d'une application web, notre code php est sur le serveur, en utilisant le singleton je force tous mes utilisateurs à utiliser la même instanciation de la connexion, ce qui nous fait qu'un seul pont vers la bdd et donc un gain de performances, j'ai bien compris?
Mais n'y a t'il pas un risque d'embouteillage sur ce pont si on a beaucoup d'utilisateur?
Je me pose une autre question. Quand j'instancie un objet provenant de ma bdd, par exemple je crée une instance de ma classe user en utilisant les données d'un row de ma table user dans ma bdd. Je fais mon select dans ma bdd, je récupère mes données, je fais des modifs, je les envois à ma bdd avec mon update. Quand j'arrête d'utiliser on objet, est il mieux que je le détruise? Car je me dis qu'à force si je les laisse, tous les objets que je vais créer au fil du temps vont faire saturer mon serveur. Comme j'ai ma bdd je n'ai pas besoin de les garder, peut être un temps pour accélérer l'accès aux données... Des idées pour gérer?
Pour le moment je vois :
- Utilisation systématique du destructeur après utilisation de l'objet
- Script planifié de destruction des objets contenu sur le serveur (une sorte de dépoussiérage régulier)
RE: POO et DB - Zamentur - 17-04-2010
Alors déjà tu te trompes sur pas mal de chose:
Citation :Mais dans le cas d'une application web, notre code php est sur le serveur, en utilisant le singleton je force tous mes utilisateurs à utiliser la même instanciation de la connexion, ce qui nous fait qu'un seul pont vers la bdd et donc un gain de performances, j'ai bien compris?Non pas du tout, le singleton permet juste de forcer à réutiliser la même instance de classe au cours de l'exécution d'une page. Donc le singleton ne te permet pas de permettre à tes utilisateurs d'utiliser la même connexion à la bdd.
D'ailleurs dans la plupart des applications web cette connexion est recréé à chaque début de page et fermé à la fin de cette dernière. Pour empêcher çà il faut demander une connexion persistante mais tous les hébergements ne le permette pas.
Citation :Mais n'y a t'il pas un risque d'embouteillage sur ce pont si on a beaucoup d'utilisateur?Justement si tu utilise les connexions persistante si 2 scripts s'exécutent en même temps elles ouvriront une seconde connexion persistante, si mes souvenir sont bon, car il n'est pas possible avec un serveur xamp d'utiliser la même connexion sur 2 page s'exécutant au même moment (ceci étant j'ai pas essayé, pour tester on pourrait transmettre la ressource par session/fichier)
Citation :Quand j'instancie un objet provenant de ma bdd, par exemple je crée une instance de ma classe user en utilisant les données d'un row de ma table user dans ma bdd. Je fais mon select dans ma bdd, je récupère mes données, je fais des modifs, je les envois à ma bdd avec mon update. Quand j'arrête d'utiliser on objet, est il mieux que je le détruise? Car je me dis qu'à force si je les laisse, tous les objets que je vais créer au fil du temps vont faire saturer mon serveur. Comme j'ai ma bdd je n'ai pas besoin de les garder, peut être un temps pour accélérer l'accès aux données... Des idées pour gérer?Comme je l'ai dit les objets créés au court d'un script sont détruit à la fin. Ils sont aussi détruit si il n'y a plus de référence qui pointe vers eux.
Donc si tu unset() chaque référence quand tu n'en a plus besoin tu détruit l'objet.
Peut être aussi est il possible de détruire directement en appelant le destructeur.
Détruire les objets avant la fin peut être souhaitable si ils s'avèrent que ces derniers sont volumineux et consomme beaucoup en mémoire vive.
Un autre cas ou il faut nécessairement détruire les objets créé c'est la création d'un serveur socket qui tourne à l'infinie. Il faut alors faire très attention sur ce point pour éviter une montée en charge au fur et à mesure du temps.