[Framework] Avantages et inconvénients ?

[Framework] Avantages et inconvénients ? - Version imprimable

+- 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 : [Framework] Avantages et inconvénients ? (/showthread.php?tid=2900)

Pages : 1 2 3 4 5 6 7 8

RE: [Framework] Avantages et inconvénients ? - Zamentur - 20-08-2008

Citation :Oracle et pgsql sont plus stricte que MySQL, donc toute les requetes de jointures peuvent ne pas fonctionner si tu changes de base.

MySQL peut être passé en mode ANSI, afin de coller au standard SQL ANSI(sauf sur ce que MySQl ne sait pas faire).
Si on pressent un changement de base, il est plus simple de s'en tenir au possibilité de SQL ANSI que d'utiliser toute une classe d'abstraction supplémentaire non?

Enfin en apparence çà me semble mieux.

RE: [Framework] Avantages et inconvénients ? - zzarbi - 20-08-2008

Zamentur a écrit :
Citation :Oracle et pgsql sont plus stricte que MySQL, donc toute les requetes de jointures peuvent ne pas fonctionner si tu changes de base.
MySQL peut être passé en mode ANSI, afin de coller au standard SQL ANSI(sauf sur ce que MySQl ne sait pas faire).
Si on pressent un changement de base, il est plus simple de s'en tenir au possibilité de SQL ANSI que d'utiliser toute une classe d'abstraction supplémentaire non?

Enfin en apparence çà me semble mieux.

Oui vaudrait mieux faire du code ANSI. Mais si on présent un changement de bdd, PDO reste interessant car chaque extension de base de donnée possède leur propres méthodes.
Par exemple pour lancer une requete ça pourrait être :
- pour mysql, mysq_query();
- pour oracle, oracle_query(), suivi d'un commit() pour valider la modification... (Ou autocommmit, etc...)

Mais comme les extensions sont différentes, il faut un "quelque chose" pour unifier le tout, et c'est là que PDO intervient. Il permet de s'affranchir des différentes extensions, ils unifient le tous.

Mais on ne prévoit pas de changement de BDD ça ne sert à rien, cependant ce n'est pas plus lent (je crois) niveau performance que d'utiliser mysqli ou mysql...

RE: [Framework] Avantages et inconvénients ? - QuentinC - 20-08-2008

Donc en gros c'est un truc inutile ? Du moins ce n'est pas plus utile que mysqli ou mysql.

IL y avait un truc qui avait l'air intéressant, le mode de fetch qui remplit directement les variables d'instances.

Y'a décidément quand même plusieurs choses qui m'énervent avec php en mode objet :
- Les strings et les arrays ne sont pas des objets, et on ne sait pas toujours l'ordre des paramètres dans les fonctions.
-- il faut toujours répéter $this pour les variables et les méthodes d'instances. J'oublie toujours et c'est hautement inutile...

RE: [Framework] Avantages et inconvénients ? - zzarbi - 20-08-2008

QuentinC a écrit :Donc en gros c'est un truc inutile ? Du moins ce n'est pas plus utile que mysqli ou mysql.

Bah pour faire de l'abstraction c'est utile. Mais si on vise pas de changer de base... L'abstraction est inutile. Mais je veux dire que c'est pas le problème de PDO c'est générale aux classes d'abstractions.

Mais c'est un design pattern, si dans le cas d'une BDD en PHP c'est pas utile ça pourrait être utile pour d'autres problèmes.

RE: [Framework] Avantages et inconvénients ? - Zamentur - 20-08-2008

zzarbi a écrit :Par exemple pour lancer une requete ça pourrait être :
- pour mysql, mysq_query();
- pour oracle, oracle_query(), suivi d'un commit() pour valider la modification... (Ou autocommmit, etc...)

Attention j'ai pas dit qu'il fallait pas faire d'abstraction, le changement d'API n'est pas le seul avantage.

Imaginons qu'on souhaite calculer le temps des requêtes si on a mysql_query() partout on ne pourra pas le faire, avec une classe d'abstraction çà se fait en 2 minute.
De plus il y a d'autre avantage à faire une classe sql, par exemple pour faire des raccourcie.
Par exemple quand on souhaite récupérer une donnée, moi je trouve toujours long de faire:

Code PHP :
<?php 

$id=mysql_real_escape($id);

$req=mysql_query("SELECT truc FROM machin WHERE nom='$nom'") or die (mysql_error());

$data=mysql_fetch_row($req);

$truc=$data[0]; 

Donc grâce à ma classe d'abstraction actuel, j'ai quelques chose du genre:

Code PHP :
<?php 

$truc= $db->query("SELECT `truc` FROM `machin` WHERE `nom`='%s' LIMIT 1",$nom); 

Sachant que si il y a plusieurs données:

Code PHP :
<?php 

$data= $db->query("SELECT `truc`,`bidule` FROM `machin` WHERE `nom`='%s' LIMIT 1",$nom);

echo $data->truc; 

Rien que pour l'allègement du code je trouve çà génial.

Et si par exemple je souhaite savoir combien de requête se font dans un script je peux mettre un compteur static dans ma classe, et le tour est joué, alors que si on a pas de classe sql çà prend un temps fou.

RE: [Framework] Avantages et inconvénients ? - zzarbi - 21-08-2008

Zamentur a écrit :
zzarbi a écrit :Par exemple pour lancer une requete ça pourrait être :
- pour mysql, mysq_query();
- pour oracle, oracle_query(), suivi d'un commit() pour valider la modification... (Ou autocommmit, etc...)
Attention j'ai pas dit qu'il fallait pas faire d'abstraction, le changement d'API n'est pas le seul avantage.
Etc...

Oui tu peux faire ça mais le pattern abstraction de base est utilisé pour unifié plusieur entrée en une sortie...
Plusieurs DB en une classe, etc...

Mais tu peux aussi alléger ton code, comme tu le proposes, personnelement je ne préfère pas. Mais c'est une question de goût non agumenté.

RE: [Framework] Avantages et inconvénients ? - QuentinC - 21-08-2008

zzarbi a écrit :Mais c'est un design pattern, si dans le cas d'une BDD en PHP c'est pas utile ça pourrait être utile pour d'autres problèmes.

C'est-à-dire ?

Zamentur > on n'est pas obligé de faire une classe pour ça. Suffit de définir ses propres fonctions et éventuellement faire un str_replace/preg_replace dans les scripts déjà existants.

Par exemple mon fichier mysql.php en procédural possède les fonctions suivantes :
- msql : requête simple qui incrémente le compteur de requêtes et qui retourne la même chose que mysql_query, en arrêtant immédiatement le script avec un message d'erreur si la requête a planté.
msqlRow : La précédente en combinaison avec un unique mysql_fetch_assoc. Raccourci stupide mais pratique.
msqlRows : Une requête de base mais qui renvoie un tableau de tableau. Raccourci encore une fois relativement idiot mais pratique.
msqlVal : Une requête pour récupérer une valeur unique, par exemple select count(*) from table. Comment dire ? Un racourci qui n'est pas inintéressant non plus.
msqlRowCount : Appelle msql et effectue une requête simple, et renvoie pas de résultat mais le mysql_num_rows. Parfois, c'est pratique... par exemple pour vérifier si un membre n'existe pas déjà avec le même pseudo quand on s'inscrit.
msqlEscape : parce que mysql_real_escape_string c'est vraiment trop long à taper.
array2sqlInsert : Transforme un tableau associatif ou un tableau de tableau associatifs en requête de type insert
array2sqlUpdate : Transforme un tableau associatif en requête de type update
getReqCount : une fonction à la place d'utiliser directement la variable globale, parce que c'est plus propre
getReqTime : Idem

Ce qui fait que je peux avoir ce genre d'appel :
[code]
$userInfo = msqlRow("select * from users where id = {$_SESSION['userId']}", __FILE__,__LINE__);
[/quote]

Je passe en plus le nom de fichier et le numéro de ligne, pour débugger facilement au cas où la requête plante. J'aimerais bien pouvoir les faire passer automatiquement, ça serait pratique mais je n'ai pas encore trouvé comment faire si toutefois c'était possible. Si par hasard quelqu'un a la petite astuce...