POO vs procedural, mysql et les debutants php

Le
Gunbaty
Bonjour,
voilà une question qui semble souvent revenir:

faut-il utiliser un objet pour abstraire le SQL du php et ainsi gagner
en clareté avec juste des Array comme requete SQL ou utiliser un mélange
SQL / PHP avec un risque d'erreur plus grand, tout cela pour produire
plus vite ?

je m'explique voici un script classique avec de SQL :


/* *************************************** */

$query_base = "select b.*, c.* from biens b left join caracteristiques c
on c.caracteristique_biens_id = b.biens_id where b.biens_category_id 2
order b.biens_prix asc ";

$query_base_cnt = "select count(b.biens_id) from biens b left join
caracteristiques c on c.caracteristique_biens_id = b.biens_id where
b.biens_category_id = 2 ";

$result = mysql_query($query_base." limit 0, 20");

$result_cnt = mysql_query($query_base);
// solution 2
// $result_cnt = mysql_query($query_base_cnt);

if($result && is_ressource($result) && (mysql_num_rows($result)>0) )
{
echo '<br /> il y a '.mysql_num_rows($result)." affich&eacute;, et au
total ".mysql_num_rows($result_cnt);
while(($line = mysql_fetch_object($result)))
{
echo "<br /> ".$line->caracteristique_description." ::
".$line->biens_prix;
}
}


/* *************************************** */

voici maintenant une alternative objet de ma conception et utilisé par
de nombreux CMS / Framework

$_obj_sgbd = new StorageManagerSGBD(); // ne se connecte que lors de
l'envoie d'une requete SQL

$result = (($_obj_sgbd->fetchEnt(
array(
"biens"=>array(

storagemanager_queryfield=>array(

"biens_prix"=>array(">"=>2000),

"biens_category_id"=>2

),

storagemanager_returnfield=>array("*"),
storagemanager_limitfield=>array(0=>20),

storagemanager_orderfield=>array("biens_prix"=>"asc")
),
"caracteristiques"=>array(

storagemanager_queryfield=>array(

"caracteristiques_biens_id"=>array("="=>"biens_id")

),

storagemanager_returnfield=>array("*"),
),
)
)
)?$_obj_sgbd:$_obj_sgbd);


if($result && count($result)>0 )
{

echo '<br /> il y a '.count($result)." affich&eacute;, et au
total ".$result->count_all();
foreach($result as $_k_biens => $_v_biens)
{
echo "<br /> ".$_v_biens->caracteristique_description." ::
".$_v_biens->biens_prix;
}
}

/* *************************************** */


Voilà pour les exemples

dans la solution 1, pour modifier la requete et nombre de resultats il
faut intervenir sur les Deux Requete et si l'on veux changer les liaison
ou critere entre les table il faut connaitre le SQL.

Dans la solution Deux, tout n'est que Array et formulation uniforme pour
toutes les requete, l'objet est prevu pour se connecter UNIQUEMENT en
car de requete SQL.

Autre chose, dans le cas de la solution Deux, le comptage TOTAL et avec
le Limit SQL est dispo de suite pas de requete supplementaire (avec
mysqli), de ce fait un devellopeur ne connaissant rien a SQL peux
l'utiliser et tout les Script profite d'une clareté avec un simple
foreach, autre avantage, le prochain resultat de BDD est chargé à chaque
passage du foreach grace a SPL ArrayIterator sur l'objet, la
reutilisation du code est simplifier car abstrait de SQL et de toutes
confusion de variable, les updates, deletes et inserts se font avec des
primitives sur l'objet tels que : fetchEnt(), insertEnt(), deleteEnt(),
toutes acceptant un Array ou une Chaine SQL.

Donc meme un débutant en php peux l'utiliser, car les indexes du Array
sont le nom SQL des colonnes de la BDD et l'indice est la condition ou
liaison dans la requete sql.

Cepandant, je fait face a un chef de projet qui me dit ne pas comprendre
mon choix en POO et pretent que le "à l'ancienne " est plus rapide et
plus clair, ce que je conteste, car le taux d'erreur sur l'ancienne
methode et plus grand et ne gere en aucun cas les erreur, si ce n'est au
prix d'un code repetitif et avec plus de variable, donc un script plus
long a charger et comprendre.


Que en pensez-vous et quel solution preferez-vous ou proposeriez vous,
voire un commentaire sur ce post ?
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Poncet
Le #23173161
Le 03/03/2011 10:00, Gunbaty a écrit :
Bonjour,



Bonjour,

voilà une question qui semble souvent revenir:



Oui, ça fait partie des marronniers ! ;-)

faut-il utiliser un objet pour abstraire le SQL du php et ainsi gagner
en clareté avec juste des Array comme requete SQL...



Pas sûr que ça "gagne" en clarté, surtout avec des tableaux
multi-dimensionnés.
Il me semble que l'objectif principal d'une couche d'abstraction est la
portabilité, donc en l'occurrence la possibilité de changer de SGBDR,
dans certaines limites, sans bousiller le code PHP.

... ou utiliser un mélange
SQL / PHP avec un risque d'erreur plus grand, tout cela pour produire
plus vite ?



Pas sûr non plus que ça "produise" plus vite, surtout si l'équipe de
développement a plutôt une culture "objet".

je m'explique voici un script classique avec de SQL : [...]



Même à ce niveau on peut se poser des questions de portabilité.
Par exemple, faut-il rester strictement dans le standard SQL, et si oui
lequel ? Le plus récent ?
Dans ton code, tu n'utilises pas la fonction moins gourmande
"FOUND_ROWS()", mais hélas spécifique à MySQL. Pourquoi ce choix ?

voici maintenant une alternative objet de ma conception et utilisé par
de nombreux CMS / Framework


[...]
Donc meme un débutant en php peux l'utiliser, car les indexes du Array
sont le nom SQL des colonnes de la BDD et l'indice est la condition ou
liaison dans la requete sql.



Voilà une autre question : pourquoi les frameworks prétendent-ils,
souvent à tord, être destinés à des débutants, voire à des utilisateurs
non développeurs ?

J'ai fait mon propre framework, parce que les usines à gaz commençaient
à me gaver, et qu'il fallait malgré tout que j'industrialise mon code.
Par contre, il n'est absolument pas réutilisable par un débutant, mais
le but n'était pas là !

Pour la partie accès au SGBDR SQL, j'ai bien sûr créé une classe dont
les méthodes surchargent plus ou moins celles des objets PDO, ce qui
offre une bonne portabilité (et plus de sécurité, aussi).
Mais j'ai conservé l'écriture des requêtes en SQL dans la plupart des
cas, car je ne voulais pas "réinventer" un deuxième langage.

Cepandant, je fait face a un chef de projet qui me dit ne pas comprendre
mon choix en POO et pretent que le "à l'ancienne ..." est plus rapide et
plus clair, ce que je conteste, car le taux d'erreur sur l'ancienne
methode et plus grand et ne gere en aucun cas les erreur, si ce n'est au
prix d'un code repetitif et avec plus de variable, donc un script plus
long a charger et comprendre.



Là, tu fais peut-être face à un choix d'équipe. C'est délicat de trancher.

Que en pensez-vous et quel solution preferez-vous ou proposeriez vous,
voire un commentaire sur ce post ?



La mienne, si je n'ai pas de contrainte de travail en groupe.
En tous cas, j'essaye de coder simple pour faire complexe, et non pas
l'inverse.

A ce propos, j'étais très enthousiaste à la sortie du framework Zend,
pensant que l'équipe qui avait redéveloppé le moteur PHP ne pouvait
produire que de l'ultra optimisé. J'ai vite déchanté !
Il faut dire que je râle quand mon framework, en mode debug local, me
sort une page web complète en plus de 10ms (sans cache).

Finalement, on retrouve la même problématique avec les moteurs de
template, genre Smarty (il en fait voir de toutes les couleurs ?).
Le mien est ultra simple, ne gère pas les boucles imbriquées, ce qui est
très facile à contourner pour un développeur confirmé.
L'avantage, c'est qu'il affiche des temps de traitement qui me
dispensent totalement de la nécessité d'un système de cache.
Qui dit mieux ?


--
Cordialement,
Pascal
Mickael Wolff
Le #23173561
FU2: fr.comp.developpement

L'OP a multi-posté un peu partout dans Usenet, plutôt que de choisir
le bon forum. C'est mal.
J'essaye de rappatrier la discussion sur fr.comp.developpement.

On 03/03/11 14:45, Pascal Poncet wrote:

Oui, ça fait partie des marronniers ! ;-)


Au delà d'un maronier, c'est surtout un débat vaste. D'ailleurs,
débutant qu'il ai, il est passé à côté de l'arme ultime dans ce débat :
la programmation fonctionnelle.

Pas sûr que ça "gagne" en clarté, surtout avec des tableaux
multi-dimensionnés.


Je ne suis pas d'accord. Bien formaté, une API qui prend des tableaux
en paramètres est beaucoup plus maintenanable qu'un gloubigoulba de
concaténations.

Il me semble que l'objectif principal d'une
couche d'abstraction est la portabilité, donc en l'occurrence la
possibilité de changer de SGBDR, dans certaines limites, sans
bousiller le code PHP.


Plutôt que de portabilité, je parlerais de généricité. Ceci dit, le
sujet de l'OP est plutôt le choix de style de programmation plutôt que
du choix d'une couche d'abstration de la base de données, voir d'un ORM.

Pas sûr non plus que ça "produise" plus vite, surtout si l'équipe de
développement a plutôt une culture "objet".


Produise, non, au contraire, c'est plus long. Par contre, les
changement peuvent être réalisés plus rapidement car on aura écrit des
tests, et que chaque fonction/classe à des responsabilités précises et
déterminées par l'interface et la documentation.

Même à ce niveau on peut se poser des questions de portabilité. Par
exemple, faut-il rester strictement dans le standard SQL, et si oui
lequel ? Le plus récent ? Dans ton code, tu n'utilises pas la
fonction moins gourmande "FOUND_ROWS()", mais hélas spécifique à
MySQL. Pourquoi ce choix ?


Je pense que c'est un non-choix, il ne doit pas connaître (pas plus
que je ne le connaissais pas. D'ailleurs, l'intérêt d'une encapsulation
de la construction des requêtes, c'est justement de permettre
l'utilisation des spécificités d'une base de données sans avoir à y
penser dans chaque code métier.

Voilà une autre question : pourquoi les frameworks prétendent-ils,
souvent à tord, être destinés à des débutants, voire à des
utilisateurs non développeurs ?


Ça vient certainement de la culture Java. Comme me le disais il y a
quelques années un ami chef de projet d'équipes Java : « Évidement Java
est un langage moins puissant que C++ et l'implémentation sera moins
performante. Mais l'intérêt de Java réside dans le fait qu'il propose un
environnement borné (règles strictes de codage, IDE traditionnellement
imposé, méthodes de travail, etc), pour qu'un développeur moyen puisse
produire du code fonctionnel, là où en C++ il aura fallut un expert. Le
coût ne sera pas le même. »


J'ai fait mon propre framework, parce que les usines à gaz
commençaient à me gaver, et qu'il fallait malgré tout que
j'industrialise mon code. Par contre, il n'est absolument pas
réutilisable par un débutant, mais le but n'était pas là !


Et tu n'en es pas au stade de te rendre compte que tu as toi-même
créé une usine à gaz ? ;)

Pour la partie accès au SGBDR SQL, j'ai bien sûr créé une classe dont
les méthodes surchargent plus ou moins celles des objets PDO, ce qui
offre une bonne portabilité (et plus de sécurité, aussi). Mais j'ai
conservé l'écriture des requêtes en SQL dans la plupart des cas, car
je ne voulais pas "réinventer" un deuxième langage.


Tu composes à partir un PDO ?

Là, tu fais peut-être face à un choix d'équipe. C'est délicat de
trancher.


Et à vivre avec, surtout. Parce qu'on oublie souvent de prévenir les
développeurs que l'essentiel de notre travail, c'est la communication,
et l'acceptation des choix et éventuelles erreurs des autres.

La mienne, si je n'ai pas de contrainte de travail en groupe. En tous
cas, j'essaye de coder simple pour faire complexe, et non pas
l'inverse.


KISS ? :D (oui, j'aime les buzzwords)

Finalement, on retrouve la même problématique avec les moteurs de
template, genre Smarty (il en fait voir de toutes les couleurs ?). Le
mien est ultra simple, ne gère pas les boucles imbriquées, ce qui est
très facile à contourner pour un développeur confirmé. L'avantage,
c'est qu'il affiche des temps de traitement qui me dispensent
totalement de la nécessité d'un système de cache. Qui dit mieux ?


Je n'aime pas les systèmes de template. Je n'en ai pas trouvé qui
gèrent correctement les problèmes liés à l'unicité des ID dans une
document HTML/XML.
Publicité
Poster une réponse
Anonyme