GERER UN ENTREPOT VIA PHP 5 MYSQL VERSION OBJET ( PDO)

Commentaire de yoman64 le 31/03/2008 13:43:47

Salut,

Euh j'ai peut être mal vu, mais tu ne déclare même pas tes variables de classe... tu appeles $this->var sans arrêt, mais je ne vois null part ou tu les à déclarées...

Tant qu'à faire du php5 tu devrais déclarer la porté de tes méthodes (public,private) et de tes variables (si tu les déclarait...).

Ensuite attention, tu n'échappes pas les arguments que tu passe à MySql, donc l'injection est possible... (Peut être que tu le fais en dehors de la classe, j'ai pas regardé, après tout l'attrait de ta source a t'entendre c'était la classe).

Ta classe renvoit souvent du html ou du texte via des echo, c'est très mauvais, apprends à utiliser les exceptions ou gère les erreurs en dehors de ta classe.

Bref encore beaucoup de boulot, mais ne te décourage pas :)

Commentaire de neigedhiver le 31/03/2008 21:54:53

Salut,

Je rejoins a priori l'avis de Yoman64 et Coucou747.
Sauf concernant l'abstraction de base de données. A croire que si on n'utilise pas une classe d'accès au SGBDR abstraite qui permet d'utiliser MySQL aussi bien que PgSQL, ORacle, MSSql ou autre, c'est mal. Moi, je ne suis pas d'accord. Quand on travaille pour soi, qu'on n'utilise que MySQL, qu'on n'utilisera jamais rien d'autre que MySQL, qu'on ne publiera jamais son code source pour le partager, je ne vois vraiment pas l'intérêt d'utiliser une classe d'abstraction.

Pour en remettre une couche quant au HTML dans la classe : l'idéal est de séparer le traitement de l'affichage. C'est plus facile pour la maintenance et l'évolution du site. L'idéal pour cela étant d'utiliser un système de templates (entendre par là, une mise en forme automatisée des données d'après des gabarits, pas forcément utiliser Smarty ou autre moteur).
La logique veut qu'une classe de traitement de données va traiter les données, et uniquement ça. Leur affichage doit pouvoir se gérer séparément (ce qui permet de modifier la sortie, sans toucher au traitement, par exemple, produire du HTML, ou alors du XML pour utiliser sur un extranet, du PDF, et j'en passe).

Quant aux erreurs, jette un oeil aux exceptions et à trigger_error() : toujours pareil... Une classe, si elle ne peut pas travailler, va s'arrêter, et c'est le reste du programme qui se charge de gérer l'erreur. De ce côté là, t'es pas très loin de l'idée... Mais tu as encore du code redondant que tu pourrais factoriser. Pour cela, tu peux définir un gestionnaire d'erreurs (voir : set_error_handler() et set_exception_handler()). Ta classe se contente de générer une erreur (avec trigger_error si ce n'est pas une erreur fatale, ou throw new Exception si c'en est une) qui sera gérée par le gestionnaire : ça te permet de modifier plus tard la manière dont tu gères les erreurs (simple affichage, log dans un fichier, ...) sans avoir besoin de te retaper tout ton code pour changer 250 fois les mêmes lignes.

Commentaire de neigedhiver le 31/03/2008 23:18:23

@Malalam :

"une exception n'empêche pas de continuer un code (après le catch)"

Certes... Mais je crois que je vais lancer un vrai débat sur la question...  Marcus Börger (un des auteurs de php) a dit :
"Respect these rules :
- Exceptions are exceptions
- Never use exceptions for control flow
- Never ever use exceptions for parameters passing"
Cf : http://somabo.de/talks/#20050401

Mais c'est pas vraiment l'endroit pour en parler... Cependant, c'est vraiment une question qu'on devrait aborder pour de vrai un de ces jours...

Commentaire de coucou747 le 01/04/2008 15:38:59 administrateur CS

ta source fait un peu vide maintenant... t'as mis une classe pdo, mais t'as vire le reste...

personellement, j'aurais imagine un truc genre :

Entrepot ---> arrayAcces
         ---> Itterator
         ---> Countable (c'est peut-etre pas vraiment utile ici)

ProduitNotFound ---> EntrepotException ---> Exception
QuantiteNegative ---> EntrepotException ---> Exception

Produit ---> SqlElement (si je mets sqlElement, c'est pour dire qu'on peut en ajouter, en supprimer, en mettre a jours, et que c'est directement relie a du sql, c'est donc pas une classe mais une interface qu'il faut faire ici)

et tu mets un array de Produit dans l'Entrepot (en private evidement)


si tu veux t'amuser avec une syntaxe marrante, tu peux mettre Produit implements coutable, ca te permettrait de faire un truc genre :

$a=Produit::GetById(15);
echo 'il y a '.count($a).' produits dans l\'entrepot.';

si tu veux lister les deplacements de produits (entrees, sorties) tu peux t'amuser a donner a produit le meme genre d'interfaces (itterator) et a ajouter trois classes pour ces entrees, sorties (une E, une S, et une interface ou abstraite).

Commentaire de fabienenvac le 01/04/2008 17:41:18

effectivement il manque des morceaux, la je suis entrain de tous transformer mes requêtes avec pdo.
je pense donc pouvoir mettre en ligne le reste d'ici ce soir et après réfléchir sur des objets propres a l'entrepôt.
Si qqn peut me donner un exemple afin de transmettre mon objet connexion cela serait appréciable.
merci