Discussion :

[frkta]

J'utilise PRADO l'ancetre de Yii qui est toujours maintenu et qui a je trouve une bonne gestion des ORM. C'est assez confortable pour de simples requetes (CRUD) mais quand ça devient complexe...y a pas le choix faut aller sur le natif.

[madvic]

Personnellement je reste dubitatif !! :

Je pose la question à vous, les grand développeurs, vous trouvez cela vraiment plus simple ?
Moi qui fait un peu de php et bcp de SQL au travail, je trouve ce code illisible, quelqu'un qui reprend va mettre pas mal de temps à comprendre. Et je trouve que ca ne fait rien gagner au niveau écriture...
De plus si vous dites que ça ralentie le tout...
Comment faire compliqué quand on peut faire simple !

[koyosama]

Je ne suis pas très fan des ORM.
Si on fait de l'ORM Database First, pourquoi pas. Créer la base de données d'abord permet d'avoir une compréhension et optimisation des bases de données.

Tant qu'on comprend la base de données, il n'y pas de problèmes.
Par contre, il y a des ORM qui fait des relations virtuellement avec les tables et parfois c'est dérangeant car cela me permet de créer m'importe quoi comme données.

Je pense aussi qu'on exploite pas assez les procédures stockées, les triggers, les moteurs de bases de données.

ORM peut être aussi lourds car il charge beaucoup de données en mémoire.

Mais pour maintenir les applications, l'ORM est utile car il te permet une logique de base que m'importe quel développeur peut comprendre.

[erwanlb]

Personnellement je reste dubitatif !! :

Je pose la question à vous, les grand développeurs, vous trouvez cela vraiment plus simple ?
Moi qui fait un peu de php et bcp de SQL au travail, je trouve ce code illisible, quelqu'un qui reprend va mettre pas mal de temps à comprendre. Et je trouve que ca ne fait rien gagner au niveau écriture...
De plus si vous dites que ça ralentie le tout...
Comment faire compliqué quand on peut faire simple !

Je fais pas de php et je vois rien d'illisible dans ce code... ???

Ce qui peut être illisible c'est quand t'as pas l'habitude de faire du SQL...et faire du code homogène plutôt qu'un mélange avec du SQL dedans, perso je préfère...

Pour les ralentissements, humainement pas vu de différences....et je m'amuse pas à benchmarker à la milliseconde...j'ai des utilisateurs comme clients, pas des chronomètres...alors entre 254,5ms et 467,12ms....l'utilisateur s'en bat les boules...

[zevince]

Bonjour,

Moi j'utilise Propel depuis des années (depuis la version 1.2).
Je dois avouer que me relancer sur du SQL brut ca me paraitrait un sacré bond en arrière !

Au niveau performances, si on ecrit bien son code, propel optimise vraiment très bien les requetes, supporte les jointures, les champs particuliers, type count, max, min, etc..
L'hydratation est également bien pensée, pour les requêtes lourdes.
L'organisation des objets est très souple et permet de gérer tous les cas particuliers.

Je n'ai pas fait de benchmarks, mais je l'utilise sur de nombreux sites, y compris intégré à Symfony2 ou à Silex en remplacement de Doctrine (que je n'apprécie pas du tout, malgré pas mal d'efforts pour essayer de m'y mettre). J'ai toujours trouvé propel extrêmement rapide, même si je n'ai pas de chiffres.

D'ailleurs, les simples insertions en base ne sont pas les requêtes les plus fréquentes.. Pour moi ce sont plutôt les Select avec jointures qui doivent être rapides.

Voila, juste un avis de plus sur la question..

[Gugelhupf]

me relancer sur du SQL brut ca me paraitrait un sacré bond en arrière

[Traroth2]

Dans le monde Java, on a coutume de distinguer les ORM comme Hibernate ou JPA des systèmes de persistance comme MyBatis. La différence est qu'un ORM est supposé gérer toute la plomberie liée aux bases de données et donc éviter d'avoir à écrire des requêtes SQL, quitte à inventer de toutes pièces un nouveau langage comme HQL ou JPQL.

Personnellement, je m'en sers quand c'est une exigence du projet. Sinon, je trouve que les bénéfices concrets sont trop faibles par rapport aux inconvénients.

Pour moi, le seul bénéfice réel est de s'abstraire du système de base de données utilisée, ce qui permet de passer de l'un à l'autre avec un effort minimal. Il faut toutefois avoir conscience qu'on pallie simplement la faiblesse de la norme SQL, qui devrait en principe être commune à tous les SGBD.

Les inconvénients, eux, sont nombreux : perte de performances, obligation d'apprendre une nouvelle syntaxe spécifique, apparition de bugs exotiques et pas évidents à comprendre au départ (genre "detached entity passed to persist" ou "LazyInitializationException").

Personnellement, je préfère largement les frameworks de persistance comme MyBatis, qui prennent simplement en charge la gestion des ressources et permettent de centraliser la gestion des requêtes, sans compliquer les choses en essayant de les simplifier.

J'ajoute que j'ai une forte expérience en SQL et que je trouve dommage de ne pas pouvoir utiliser mon savoir-faire à cause d'un ORM.

[erwanlb]

J'ajoute que j'ai une forte expérience en SQL et que je trouve dommage de ne pas pouvoir utiliser mon savoir-faire à cause d'un ORM.

C'est ne pas penser à ceux qui au contraire ont une faible expérience en SQL (voir pas du tout) et qui seront surement plus à l'aise avec un ORM...

Ca me fait penser au débat ligne de commande/interface graphique

[rasta tom]

Un autre avantage a utiliser un ORM connu (comme Doctrine ou Propel pour php) c'est pour l'arrivée de nouveaux dev sur le projets: s'il connait deja l'ORM en place on gagne en temps de formation.
Si on a un dev "pseudo-guru" qui met en place son systeme de gestion des données que lui seul peut comprendre a base de proc de triggers etc, le projet devient plus difficile a reprendre et dépendent du dev initial.
C'est globalement l'avantage d'utiliser des lib populaires plutot que de refaire soit meme (orm, framework, ...)

Ensuite au niveau debug, sans etre expert mais pour y avoir dejà un peu mis le nez, je trouve ca assez lourd de faire ca dans mysql plutot que dans php (mais il existe peut etre des outils pour ca, genre XDebugMysql !)
En plus sur mon ORM favoris je peux mettre le nez dans le code si j'atteinds des cas limites, pour comprendre le fonctionnement et m'y adapter, voir même pour ajouter des fonctionnalités ou faire des corrections, ce dont je serais bien incapable pour un sgbd

Un mot sur les perf pour finir; au niveau sql pure les requetes générés sont généralement assez bien optimisées et si on en fait pas n'importe quoi l'ORM ne fait pas 50 requetes pour rien. Par contre c'est généralement plus facile de faire des boulettes sans s'en rendre compte à cause des méchanisme de lazy-loading par exemple, mais la c'est le dév qu'il faut blamer, pas l'ORM !

[Traroth2]

C'est ne pas penser à ceux qui au contraire ont une faible expérience en SQL (voir pas du tout) et qui seront surement plus à l'aise avec un ORM...

Ca me fait penser au débat ligne de commande/interface graphique

Je ne suis pas persuadé qu'apprendre HQL soit fondamentalement plus facile qu'apprendre SQL. On ne fait donc que repousser le problème.

[erwanlb]

Je ne suis pas persuadé qu'apprendre HQL soit fondamentalement plus facile qu'apprendre SQL. On ne fait donc que repousser le problème.

C'est plus transparent dans un développement que d'y mettre des lignes SQL et une barda de lignes pour la connexion, etc...

Mais je connais pas HQL....

[anikon]

Par contre il faut préciser que zend db n'est pas un ORM.

[imikado]

C'est bien mais papajoker a raison.

Il faudrait développer un peu plus

@anikon Quand j'écris zendDb c'est un abus de langage, je parle de Zend_Db_Table_Abstract

[anikon]

Oui oui j'avais compris mais le module complet zend_db n'est pas un orm. C'est un composant pour coder proprement sa partie modele et s'affranchir de l'écriture de certaines requêtes SQL simple mais il n'y a aucun mapping objet.

[imikado]

D'ailleurs une chose fort dommage sur zendF 1.* c'est le fait qu'il ne génère pas la couche modèle: il ne fait que créer des classes vides à remplir soi-même
Je ne sais pas si cela a changé avec la branche 2

[papajoker]

C'est bien mais papajoker a raison.

Il faudrait développer un peu plus

J'ai posté 2 ou 3 fois sur le sujet imikado ! pas encore compris, j'ai des doutes.

ton code est ANTI orm
tu désynchronises tes objets des tables et tu oses parler de mapping objet derrière.

tu es marqué expert ici, et tu mets en exemple de code orm, LE code qu'il ne faut pas, il est normal de changer ton exemple ... ou si tu le laisses ... tu donnes l'exemple parfait pour que les débutants trébuchent.

ps: moi aussi je fais des bourdes, pas de probleme, mais il ne me faut pas 24heures pour le voir lorsque l'on me le dit.

[imikado]

Je réponds à chacun de vos posts, arguments et exemple de code à l'appui

Je ne comprends pas cette phrase:

ton code est ANTI orm
tu désynchronises tes objets des tables et tu oses parler de mapping objet derrière.

Vous avez une classe par table, vous regrouper l'ensemble des méthodes (et donc requetes) dans chacune des classe, pourquoi je "desynchronise" les objets des tables ?
Vous pouvez aussi bien manipuler un objet représentant votre enregistrement en base

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
$oArticle=model_article::getInstance()->findById(4);
$oArticle->monChamp="ma valeur";
$oArticle->save();

Que faire appel à une méthode plus optimal (plus performante) pour executer une procedure stoquee ou une simple requete UPDATE/DELETE ou autre

C'est plus flexible et basé sur les besoins que j'ai pu voir dans le monde pro, ou l'on veut toujours un subtil mélange de productivité (à coder) et de performances (d'ou la possibilité d'executer des requetes quand necessaires)

note: ce que je dit ici est autant valable avec l'ORM de Zend, yii que sur le mien

tu es marqué expert ici, et tu mets en exemple de code orm, LE code qu'il ne faut pas, il est normal de changer ton exemple ... ou si tu le laisses ... tu donnes l'exemple parfait pour que les débutants trébuchent.

Je ne comprends pas en quoi mon exemple est mauvais: comme dit plus haut on veut aussi bien pouvoir facilement manipuler des objets, qu'effectuer certaines actions performante: c'est ainsi sur des projets pro: tout n'est pas noir ou blanc

ps: moi aussi je fais des bourdes, pas de probleme, mais il ne me faut pas 24heures pour le voir lorsque l'on me le dit.

Je veux bien avouer avoir fait une bourde à partir du moment ou je comprends le problème

[imikado]

Je pense à une chose qui est peut-etre à l'origine d'un quiproquo:
dans mon ORM on a deux types de classes: model_maTable et row_maTable

model_maTable représente le "factory" execute les requetes et retourne des objets ou tableau d'objets row_maTable

row_maTable représente l'item "intelligent"

Les requetes UPDATE/DELETE, et les procedures stoquees sont des methodes dans la classe "factory"

[papajoker]

je te parle de exclusivement de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
class model_article extends abstract_model{
 public function updateNbVueById($id){
  $this->execute('UPDATE article SET nbVue=nvVue+1 WHERE id=?',$id);
 }
}

ca fait 3..4 post (je radote ), j'insiste plus, sujet clos pour moi.

1 de mes post :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
$oArticle=model_Article::getInstance()->findById($id);
$oArticle->titre=$titre;
$oArticle->save();
//ou
$oArticle->nbVue=($oArticle->nbVue+1);
$oArticle->save();
 
$oArticle->updateNbVue($id);
echo $oArticle->nbVue ; // !!!!!!!!!!!! FAUX
$oArticle->save();          // !!!!!!!!!!

[TiranusKBX]

Personnellement j'ai écris une surcouche pour PDO ayant un comportement proche car les retour avec PDO ne me convenait pas

De ce fait mes requêtes maintenant me retourne directement des tableaux de données et plus des objets PDO quelque-peut embêtant à traiter.
De plus j'ai ainsi un traitement des erreurs simplifié, que du bénéfice !

Comme ma surcouche n'est pas lourde ça pompe très peut de ressource(à peine plus que PDO seul)