JeuWeb - Crée ton jeu par navigateur

Version complète : [POO PHP] mise à jour SQL dans le destructeur ?
Vous consultez actuellement la version basse qualité d’un document. Voir la version complète avec le bon formatage.
bonjour

J'ai construit il y a longtemps une classe "action" qui consomme diverses énergies (fatigue, etc...)

grosso modo ça donne :

Code PHP :
<?php 
$toto
= new action($x,$y,$z);

$toto->addTest($t); // je rajoute diverses choses pour préparer le calcul du résultat

$retour =$toto->realise(); // c'est la le sujet du post

$echo .= $toto->retourXML(); // je renvoie le résultat par des echo XML

dans ma méthode realise, je fais deux choses :
1) je contrôle la possibilité de faire ou non l'action (y a plus assez de points, etc...)

2) je calcule la consommation pour chaque paramètre

3) je fais mon update en base MySQL


jusque là ça allait bien car je lançais un ordre ajax qui ne consommait qu'une action unique (exemple couper l'arbre) par script

maintenant je travaille sur mon système de combat et oh drame, oh désespoir, un combat (donc un script, donc un ordre ajax) est constitué de plusieurs (beaucoup) d'actions

et là je me dis, faire autant d'update sur la même clef qu'il y a d'actions c'est beaucoup trop, un update concluant l'ensemble du combat serait plus pertinent (il ferait une seule mise à jour en base de données qui serait l'agrégation de toutes les actions)

Aussi je réfléchis à modifier un peu ma classe en sortant la mise à jour SQL de la méthode realise

et là deux choix, soit le destructeur, soit une méthode "update"


Code PHP :
<?php 
$toto
= new action($x,$y,$z);

while (
condition)
{
$toto->addTest($t); // je rajoute diverses choses pour préparer le calcul du résultat

$retour = $toto->realise(); // le même qu'avant mais sans le update Mysql

$echo .= $toto->retourXML(); // je renvoie le résultat par des echo XML

}
$toto->majBDD();

est ce pour vous la bonne démarche ?

de plus le soucis du majBDD c'est qu'il faut penser à le taper... Est ce que le mettre dans le destructeur est une bonne idée ou une fausse bonne idée ?

merci de vos avis Smile
Je penche plus pour une méthode "update" qui me semble être à la fois plus clair pour le code et également plus facile d'utilisation.
Si tu reprends ton code 6 mois plus tard, tu vas vite oublier que ta classe action fait une mise à jour BDD à chaque appel du destructeur.
Également, si tu souhaites un jour utiliser ta classe action pour effectuer un combat qui ne sera pas directement mis à jour dans la base, tu te retrouveras vite embêter avec une "automatisation" du destructeur. ^^'

Voilà c'est mon avis, ceux des autres m'intéressent également. :p
Oublie les destructeurs : des fois ils ne sont pas appelés parce que PHP sait pas gérer sa mémoire (cas des références circulaires), et surtout si jamais tu oublies de faire ton unset() et que tu comptes sur ton destructeur en fin de script : qui dit que l'objet de connexion à la bdd ne sera pas détruit *avant* ton objet ? et dans ce cas, oubliée la requête Smile
naholir à raison; comme qui dirais je fais aussi plus confiance au constructeur qu'au destructeur:
- la destruction en fin de script quand PHP fait son nettoyage c'est problèmatique, ordre de destruction des objets pas fiable sans compter que j'ai pas trouvé comment gérer les exceptions et autre erreurs comme je le voudrais (galère si tu as déjà envoyé le contenu au client; de tout à coup revenir en arrière ou de l'avertir parce que tu plante ta majBDD)

- dans les autre cas tu préfère quoi: une version explicite: $toto->majBDD() ou implicite: supprimer($toto); dans les 2 cas finalement tu as une commande que tu dois écrire, non ?
(à part bien sûr si tu fais déjà la destruction parce que t'as des objets volumineux, ou je sais quelle raison; dans ce cas là effectivement si t'as confiance dans la destruction explicite de ton objet autant profiter.)

autre variante que tu peux faire c'est une gestion de type événementiel:
dans le constructeur de $toto (ou a un autre moment: après tout si l'objet est pas modifié pourquoi faire un appel automatique à majBDD ) tu l'enregitre dans une pile:
gestionnaire->enregistrer('justeavantaffichage',$toto->majBDD);

et dans ton programme; juste avant d'envoyer la page tu auras un appel pour executer le contenu de ta pile:
gestionnaire->lancer('justeavantaffichage');


en terme de codage: tu as toujours une commande à écrire quelque part
soit "$toto->majBDD", soit "gestionnaire->enregistrer('justeavantaffichage',$toto->majBDD)" soit detruire($toto).
je préfère les 2 premières options. (la première: parce que c'est explicite; la 2e pour sa souplesse). La 3e... j'ai de la peine, j'ai été traumatisé par des débugage foireux sur des destructions anarchiques.
merci à tous

même si vous me faites mal au coeur avec cette histoire de destructeur ^^

sinon j ai choisi la solution $toto->majBDD() avec une petite variante

comme j'utilisais déjà ma classe à divers endroits, pour éviter de changer le code un peu partout, j ai laissé le comportement

je modifie en mémoire ==> je modifie en base

mais au lieu d etre le seul comportement, c est le comportement "par défaut"

si je veux avoir la main sur l'enregistrement alors je code ainsi

Code PHP :
<?php 
$toto
= new action($x,$y,$z);

$toto->pasDeMajBDDParDefaut();

while (
condition)
{
$toto->addTest($t); // je rajoute diverses choses pour préparer le calcul du résultat

$retour = $toto->realise(); // le même qu'avant mais sans le update Mysql

$echo .= $toto->retourXML(); // je renvoie le résultat par des echo XML

}
$toto->majBDD();


au moins c est explicite, je ne peux pas oublié de sauvegarder :

soit je sauvegarde a chaque realise, quitte a perdre en performance
soit je dois penser a annuler la sauvegarde auto, donc penser juste après a positionner la sauvegarde manuelle