Discussion :

[JackDaniels93]

C'est sûr qu'hydrater (convertir en objets) un gros volume de résultats n'est pas conseillé. Mais j'ai refait un test à l'instant et je récupère 1000 lignes de ma BDD (MySQL aussi) avec Doctrine2, sans aucune optimisation particulière, en moins de 300 ms tout compris. La debug toolbar me chiffre le temps de requête à moins de 3 ms. Pour l'affichage je colle ça dans un <pre>, mais ça n'a pas d'importance.
Pour le cache j'ai juste APC d'installé, c'est tout.
Je fais un bête findAll pour récupérer mes objects :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
public function homeAction()
{
    $repo = $this->getDoctrine()->getManager()->getRepository('MGLabBundle:Author');
    $authors = $repo->findAll();
 
    return $this->render('MGLabBundle:DoctrineBench:home.html.twig', array(
            'authors' => $authors,
        )
    );
}

[papajoker]

@imikado

je continue ma conversation de Google+

1ere partie tu parles d'ORM mais je vois plus le M de Mvc
"vous allez dans un premier temps écrire toutes vos requêtes dans un fichier php." cool avec pdo je n'écrit pas dans un fichier php ?

"vous souhaitez organiser un peu mieux, vous allez regrouper les requêtes par table" pas avec pdo ?

"vous aller créer un fichier/une classe pour les éléments récurrents (connexion, requête…) " zut c'et ce que je faisais avec pdo ...

Les avantages sont multiples:
1)Organiser vos requêtes
2)Gagner du temps à l’écriture
3)Bénéficier des avantages du design MVC*

1) pdo c'est pas pas objet ?
2) organisation MVC oui
3) je peux utiliser orm sans mvc et Mvc sans pdo, avant le debut de pdo, je me suis fait une classe Modele.

Nous sommes d'accord le Modèle c'est tres bien

perso j'utilise un ORm pour :
(si possible) utiliser langage de l'ORM car je devient indépendant du moteur, oui sql pour mysl, oracle ou postgresql pas toujours compatible.
utiliser aussi avec du nosql (MongoDB...)
meme chose pour creation et migrations : indépendance du language
outils intégrés
comme le cache : articles->remember(100)->all()
liaisons tableUne->id(40)->tableDeux->titre()

--------------------
partie bench

c'est comme si tu écris un article :
php avec ou sans framework

et ensuite pour conclure un petit bench qui me donne :

Code :

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

1
2
3
php hyper rapide
framework légé 3x + lent
framework big 20x + lent

test fait sur un "Bonjour monde" ! encore heureux que tu arrives a cette conclusion !

je n'ai jamais vu un article disant programmez avec un framework php et finissant par nous dire ils sont lents et bien sur pas un seul mot sur les différences entre ces frameworks

[phryos]

ORM sucks... Pour des petits trucs, ça marche très bien. Dès que l'on veut faire des choses plus compliqué en utilisant réellement les fonctionnalités de la bdd, faut faire du natif car rien ne passe... Quand on demande d'avoir une appli qui répond rapidement, les requêtes élaborées automatiquement par l'ORM trouve vite leur limite.

Dès qu'il y a un bug, ou un problème de synchronisation, on peut passer du temps et je ne suis pas convaincu au final que l'on gagne tant que ça en partant de zéro.

Utilisation d'hibernate + querydsl sur base de données oracle.

[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 !

[imikado]

Bonjour, premièrement je tenais à vous remercier pour ses échanges, sur vos réactions qu'elle soient ou non dans mon sens, il est toujours agréable d'échanger sur le sujet

@imikado
je continue ma conversation de Google+
1ere partie tu parles d'ORM mais je vois plus le M de Mvc
"vous allez dans un premier temps écrire toutes vos requêtes dans un fichier php." cool avec pdo je n'écrit pas dans un fichier php ?
"vous souhaitez organiser un peu mieux, vous allez regrouper les requêtes par table" pas avec pdo ?
"vous aller créer un fichier/une classe pour les éléments récurrents (connexion, requête…) " zut c'et ce que je faisais avec pdo ...

Tout d'abord merci d'avoir fait l'éffort de rejoindre le forum dvp pour continuer nos échanges (vous verrez c'est un site très agréable et interessant
Ensuite pour ces passages: dans la première partie j'essaie d'expliquer que si vous souhaitez coder "sans ORM", vous allez diviser vos requetes par table, centraliser certaines partie (connexion, requete...) et que ça revient à créer un pseudo ORM

1) pdo c'est pas pas objet ?
2) organisation MVC oui
3) je peux utiliser orm sans mvc et Mvc sans pdo, avant le debut de pdo, je me suis fait une classe Modele.

Nous sommes d'accord le Modèle c'est tres bien

1) pdo c'est objet mais c'est plus la DAO, on ne manipule pas d' "objet" au sens riche du terme
2) on est d'accord
3) bien sur, mais il est toujours plus agréable d'utiliser l'ensemble des bons concepts des frameworks MVC/ORM/DRY...

perso j'utilise un ORm pour :
(si possible) utiliser langage de l'ORM car je devient indépendant du moteur, oui sql pour mysl, oracle ou postgresql pas toujours compatible.
utiliser aussi avec du nosql (MongoDB...)
meme chose pour creation et migrations : indépendance du language
outils intégrés
comme le cache : articles->remember(100)->all()
liaisons tableUne->id(40)->tableDeux->titre()

Oui c'est en effet très confortable, ça fera l'objet d'un article qui fera un véritable benchmark des ORM avec notamment ce genre de fonctionnalité

D'ailleurs pour info, je vais très prochainement ajouter un "cachevar" qui permettra de gerer des caches de variales php (sérialisés)

--------------------
partie bench

c'est comme si tu écris un article :
php avec ou sans framework

et ensuite pour conclure un petit bench qui me donne :

Code :

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

1
2
3
php hyper rapide
framework légé 3x + lent
framework big 20x + lent

test fait sur un "Bonjour monde" ! encore heureux que tu arrives a cette conclusion !

Le mini benchmark n'était pas la pour cela:
1. il met en évidence les différences de performances entre différents ORM: j'ai trop souvent lu "les ORM c'est lourd et peu performant", c'est pour indiquer ne mettez pas tous les ORM dans le même panier
2. c'est pour avoir une idée de la perte de performance par rapport à du pdo simple: mais comme le souligne erwanlb les clients ne sont pas des chronomètres
Et ici c'est un bench avec 100 000 entrées ce qui n'arrive jamais (sans pagination) c'est plus pour avoir un ordre de grandeur.

Mais comme je l'indique, il faut mettre en balance la perte de performance avec le gain à l'écriture, l'organisation et la maintenabiblité

je n'ai jamais vu un article disant programmez avec un framework php et finissant par nous dire ils sont lents et bien sur pas un seul mot sur les différences entre ces frameworks

L'article n'est pas un benchmark entre les ORM, j'en écrirais un plus tard c'est plus un billet sur les avantages des ORM même si ils nous font perdre un peu de performances
Et comme vous avez pu le voir, on peut avoir ces performances très proche de pdo simple, beaucoup d'ORM permettent un mode rapide qui retourne de simple objets stdclass, Yii, Doctrine et bien sur le mkframework (depuis peu)

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.

Je le répète les ORM permettent de saisir nos propres requêtes
Par exemple il nous est arrivé dans nos ORM d'appeler des procédures stoquées pour gagner en performance, mais aussi des vues et autres requetes plus complexe

Il est assez rare en entreprise de migrer le SGBD d'un projet on peut donc écrire sans trop s'inquiéter des requêtes en utilisant les avantages du SGBD choisi

[papajoker]

Il est assez rare en entreprise de migrer le SGBD d'un projet on peut donc écrire sans trop s'inquiéter des requêtes en utilisant les avantages du SGBD choisi

Justement NON, aujourd'hui on réutilise des bundles(packages), si mon module d’authentification(permissions ou autre...), est réutilisable (indépendant du sql) pour 98% de mes projets c'est tout bénef

[imikado]

Justement NON, aujourd'hui on réutilise des bundles(packages), si mon module d’authentification(permissions ou autre...), est réutilisable (indépendant du sql) pour 98% de mes projets c'est tout bénef

1. Les bundles son un concept très récent arrivé zvrc sf 2 et zf 2
2. Beaucoup d'entreprises n'utilisent pas les versions 2 de ces frameworks
Mis à part ce cas, en 10 ans de dev je n'ai jamais vu de projet migrer d'un sgbd a un autre
En général une entreprise fait le choix d'un ou deux sgbd et budgette son usage, il est rare d'investir pour modifier le sgbd utilisé

[papajoker]

1. Les bundles son un concept très récent arrivé zvrc sf 2 et zf 2
2. Beaucoup d'entreprises n'utilisent pas les versions 2 de ces frameworks

pas une raison pour regarder derriere, si il est possible ont debute avec un framework relativement recent.
Pour moi, je ne regarde meme pas sous psr-1
http://www.php-fig.org/

Mis à part ce cas, en 10 ans de dev je n'ai jamais vu de projet migrer d'un sgbd a un autre
En général une entreprise fait le choix d'un ou deux sgbd et budgette son usage, il est rare d'investir pour modifier le sgbd utilisé

j'ai aussi + de 10ans de dev php mais mes années php2 .. a .. php4 sont tout sauf des références

[imikado]

pas une raison pour regarder derriere, si il est possible ont debute avec un framework relativement recent.
Pour moi, je ne regarde meme pas sous psr-1
http://www.php-fig.org/

Je n'ai pas dit le contraire, mais comme je l'indiquait c'est récent et ça ne concerne que 2 frameworks dans leur nouvelles versions (à ma connaissance)
De plus, toutes les sociétés utilisant Zend ou Symfony ne sont pas passé à la version 2 pour plusieurs raisons:
1. leurs développeurs ont acquérri au fil du temps une expertise sur la branche 1.* et sont donc productif avec
2. passer en version 2 demanderai si l'on ne devrait pas migrer les projets actuels, ce qui avec l'absence totale (et assumé) de rétro compatibilité s'avère être un projet gourmand en temps et ressources
3. les nouvelles versions radicalement différentes ne sont pas forcément au gout des développeurs qui préfére la branche 1 qu'ils trouvent plus simple

Pour http://www.php-fig.org,je ne connaissais pas, perso j'utilise sonar pour vérifier la qualité du code
cf http://dupot.org/post-10.html

j'ai aussi + de 10ans de dev php mais mes années php2 .. a .. php4 sont tout sauf des références

Et avez-vous vu en 10 ans des projets migrer d'une sgbd vers une autre, si oui pourquoi changer son fusil d'épaule ?

[Tsilefy]

@ imikado: FIG et ses PSRs est une initiative formidable entre les producteurs de frameworks et librairies pour établir un standard et des interfaces communes permettant d'interchanger ces composants sans difficultés. À mon avis, c'est la plus grand innovation en PHP depuis l'arrivée de PHP 5.2.

Et je préfère largement Symfony2 à 1.4, moins de magie et plus de contrôle :-) Mais c'est vrai, j'ai des vieilles applications en 1.4 et il est hors de question de les migrer, tant qu'elles marchent et qu'il n'y a pas de problèmes de sécurité.

[papajoker]

ça ne concerne que 2 frameworks dans leur nouvelles versions (à ma connaissance)
...
Pour http://www.php-fig.org,je ne connaissais pas, perso j'utilise sonar pour vérifier la qualité du code cf http://dupot.org/post-10.html

que 2 ? la liste ici : https://github.com/php-fig/fig-standards ils le sont déjà ou y passent demain.

Symfony, Zend Framework, Laravel, silex, Aura Project(meme framework que toi)...
et les CMS, ORM ...

Aujourd'hui la norme d'un bon framework-bibliotheque php c'est psr0..2 avec IoC

Perso suis pas dans la finance mais dans une agence web un projet est forcément court, il est donc normal de repartir a zero tous les 2 ans. et php-fig ce n'est plus jeune et reconnu par tous.

code copié de php-fig :
Nate Abele: Lithium

Nils Adermann: phpBB

Brett Bieber: PEAR, PEAR2

Guilherme Blanco: Doctrine, Doctrine2, et al.

Jordi Boggiano: Composer, Packagist

Pádraic Brady: Zend Framework

Karma Dordrak: Zikula

Paul Dragoonis: PPI, PPI2

William Durand: Propel, Propel 2

Don Gilbert: Joomla

Cal Evans: the community at large

Larry Garfield: Drupal

Ivan Habunek: Apache log4php

Paul M. Jones: Solar Framework, Aura Project

Karsten Dambekalns: TYPO3 Flow, TYPO3 Neos

Larry Masters: CakePHP, CakePHP 2

John Mertic: SugarCRM

Taylor Otwell: Laravel

Ryan Parman: Amazon Web Services SDK

Evert Pot: SabreDAV

Fabien Potencier: Symfony, Symfony2

Mike van Riel: phpDocumentor

Andre Romcke: eZ Publish

Phil Sturgeon: PyroCMS

Lukas Smith: Jackalope

Kris Wallsmith: Assetic, Buzz

David Zülke: Agavi


pour les packages il y a The League of Extraordinary Packages j'aime le nom je leurs souhaite bonne chance

[imikado]

que 2 ? la liste ici : https://github.com/php-fig/fig-standards ils le sont déjà ou y passent demain.

Aux bundles ?

Aujourd'hui la norme d'un bon framework-bibliotheque php c'est psr0..2 avec IoC

J'ai lu un peu les specs mais y a un truc qui m'embête c'est cette histoire d'indentation avec 4 espaces au lieu des tabulations, j'ai souvent eu ce débat avec des collègues.
Et je préfère les tabulations aux N espaces: peu importe l'editeur, avec des tabulations l'affichage est toujours respecté, ce qui n'est pas le cas avec une gestion via espace (selon les préferences de l'editeur) de plus on peu se retrouver avec des 3 espaces ou 6 espaces à cause d'un malheureux fleche delete sans que ça saute aux yeux.
Alors que lorsque l'on supprime une tabulation ça se voit tout de suite
Même si les tabophile ont l'air minoritaire sur google, j'aime bien cet argumentaire http://www.movementarian.org/docs/whytabs/
Et pour avoir travailler avec un collègue sous windows notepad++ et bibi sous linux geany je peux dire qu'avec les tabulations on avait pas de soucis d'indentation

Perso suis pas dans la finance mais dans une agence web un projet est forcément court, il est donc normal de repartir a zero tous les 2 ans. et php-fig ce n'est plus jeune et reconnu par tous.

Je travaille justement dans la finance, et effectivement
1. nos projets sont généralement longs (plusieurs mois)
2. on aime bien profiter de nos acquis
3. on a pas mal de projets à maintenir souvent par d'autres developpeurs, et on essaie donc d'avoir des environnemnets et applications homogènes
4. on aime bien le DRY : on essaie donc de réutiliser certaines briques entre les projets: on ne change donc pas de branche de framework souvent

pour les packages il y a The League of Extraordinary Packages j'aime le nom je leurs souhaite bonne chance

J'aime bien aussi
Effectivement pour les bundles, l'indépendance du SQL à son avantage, mais quid du de l'ORM utilisé
On peut prendre un bundle A, mais il necessitera d'utiliser le même ORM que le bundle, non ?
En tout cas j'aime bien l'idée, perso j'utilise des modules depuis 2009
Mais malheureusement je n'ai pas autant de poids pour créer un standard