Choix framework + ORM

Bonjour,

je viens poster une nième discussion à propos de choix techniques.

Après avoir parcouru pas mal de documentation, forums et tutoriels divers, je n'arrive pas à me décider.

Dans le cadre de mon stage, je souhaite réaliser une application web en php (avec du javascript pour la mise en forme). Cette application permettra essentiellement aux utilisateurs de saisir/consulter des données dans une base SQL Server qui existe déjà. Il est prévu d'y ajouter aussi des petits à-côté type gallerie d'image.

La volumétrie de la base est petite (en taille)/moyenne (en nombre de tables). Au départ il n'y aura pas plus de 20 utilisateurs simultanés (extrapolation large, si tout le monde se connecte en même temps).
L'application sera complétée à court terme par d'autres modules et la charge devrait augmenter.

En ce qui concerne mes compétences, j'ai développé quelques petites applications/site web en php et java. Habituellement je travaille sous postgresql. J'ai déjà utilisé un framework.

Comme mon code sera repris par quelqu'un d'autre, je pensais faire de l'OOP (sécurité et organisation oblige !) et j'ai zieuté du côté des frameworks. Je cherche notamment quelque chose qui génère une partie du code, au moins en ce qui concerne les modèles (la base n'est pas volumineuse mais compte 82 tables).
J'ai commencé à mettre en place FuelPhp qui semblait adapté à mon cas (prise en main facile) mais après une semaine de galère il semblerait qu'il ne soit pas prévu pour fonctionner avec SQL Server et devant mes difficultés à trouver du support dessus j'envisage de migrer...

Donc retour à la case départ :
1/ je code from scratch mais en OOP ça me fait un peu peur, je préfèrerais avoir un cadre et de la doc. Cela dit je peux utiliser db2php pour créer mes entities directement à partir de ma base.

2/ je change de framework, mais lequel alors ? J'ai envisagé ZF2 (compatible avec Netbeans, ça tombe bien) mais j'ai un peu peur du temps d'appropriation. Je ne suis pas non plus sure que ce soit nécessaire (comme Symphony 2, j'ai l'impression d'utiliser un lance-flamme pour tuer une mouche).

Bref à part SQL Server (2008 Express pour le dev, Entreprise en prod) et php je ne suis fixée sur rien.

Avez-vous des avis sur la question ?

A ta place, j'aurai opté pour SF2 ou ZF. Niveau doc, tu seras bien servis par les deux. Après pour SF, beaucoup de bundles existent, ça te machera un peu le boulot ;)

Merci, je vais l'installer et voir un peu comment il fontionne :)

Citation:

---

J'ai commencé à mettre en place FuelPhp qui semblait adapté à mon cas (prise en main facile) mais après une semaine de galère il semblerait qu'il ne soit pas prévu pour fonctionner avec SQL Server

---

D'après la donc le classe de base données supporte les drivers PDO. PDO à un driver mssql , donc à priori ça devrait marcher.

Après la seule fois où j'ai eu à travailler avec une base mssql et php je me souviens avoir pas mal galérer à cause des extensions php pas forcément compatible avec la version de mssql. peut être approfondir de ce coté là avant de tout recoder.

Je pensais également que ça fonctionnerait (j'utilise le driver non officiel pdo_sqlsrv 54 ts, la faute à XP mais de ce côté-là tout va bien !) mais en fouillant un peu dans Oil je me suis rendue compte que les requêtes ne s'appliquaient pas à SQL Server.
Par exemple pour générer les entités à partir de la base, Oil fait appel à "DESCRIBE TABLE" qui n'existe pas dans SQL Server. J'ai commencé à créer des procédures stockées pour obtenir le même résultat mais j'ai arrêté. J'ai peur qu'il y ait d'autres problèmes ensuite que je ne puisse pas résoudre.

Je ne suis qu'au tout début du développement, je préfère changer de solution maintenant plutôt que me retrouver dans le pétrin pour cause de non-compatibilité. Et si je dois tout adapter à la main je perds l'intérêt du framework !

Concernant, le framework, je choisirait plutôt codeigniter ou cake php. Ils ont l'avantage d’être plus "light" que ZF ou SF. Si j’avais à faire des applications complexes j’utiliserai probablement ce deux derniers mais ça n'a pas l'aire d’être ton cas. J'ai fait un peux de ZF, je l'ai trouvé assez lourd même si j'ai bien aimé la structure. Je suis actuellement sur codeigniter, il est sympa et light, peut être un peux trop. Il est très permissif (laxiste?) dans les conventions de codage.
Je pense que si j'en avais un à choisir actuellement, ce serai cakephp qui à l'air complet.

Concernant les ORM, que dire... J’éviterai. j'en ai eu un précédemment que j'ai viré ( perfs horribles) Une petite discussion dessus http://www.developpez.net/forums/d12...neralites-orm/.

Je pense qu'utiliser la bibliothèque d’accès à la base de données du framework devrai être suffisant pour s'assurer de la compatibilité avec la BDD.

Je vous invite à faire un tour sur ce tableau de comparaisons des différents frameworks: http://socialcompare.com/fr/comparis...rks-comparison

Et si vous souhaitez coder rapidement, je vous invite à jeter un coup d'oeil sur mes différents tutoriaux vidéos pour mettre en place une authentification, gestion de droits, CRUD, menu... ici http://mkdevs.com/screencasts.html

Citation:

---

Envoyé par bannik

Concernant, le framework, je choisirait plutôt codeigniter ou cake php. Ils ont l'avantage d’être plus "light" que ZF ou SF. Si j’avais à faire des applications complexes j’utiliserai probablement ce deux derniers mais ça n'a pas l'aire d’être ton cas. J'ai fait un peux de ZF, je l'ai trouvé assez lourd même si j'ai bien aimé la structure. Je suis actuellement sur codeigniter, il est sympa et light, peut être un peux trop. Il est très permissif (laxiste?) dans les conventions de codage.
Je pense que si j'en avais un à choisir actuellement, ce serai cakephp qui à l'air complet.

Concernant les ORM, que dire... J’éviterai. j'en ai eu un précédemment que j'ai viré ( perfs horribles) Une petite discussion dessus http://www.developpez.net/forums/d12...neralites-orm/.

Je pense qu'utiliser la bibliothèque d’accès à la base de données du framework devrai être suffisant pour s'assurer de la compatibilité avec la BDD.

---

Vu que j'ai pas mal attaqué Symfony2 je vais rester sur ce choix. Ca fait 2 semaines que j'ai fait autre chose, je reprends seulement le dev.

J'ai un souci : sur le principe "pas d'ORM" je suis d'accord. Par contre, je n'ai aucune idée de comment organiser mon code dans ce cas. C'est la première fois que je code en OO en PHP et j'ai du mal à lâcher mes repères java.

Bibliothèque d'accès à la base de données = DAO non ?

Parce qu'ensuite avec le DAL, DBAL & co je fais un joyeux mélange... Chaque fois que j'ai l'impression d'avoir compris je tombe sur une info qui me replonge dans la perplexité.

Même sans ORM :
- je crée mes entités (1 par classe) : sans ORM je ne peux pas les lier les unes aux autres ? (j'ai l'habitude des annotations @OneToMany etc)
- je configure la connexion à la BDD (SQL server) via driver pdo

Et ensuite ?

Autre question : si j'utilise l'ORM pour mapper mes entités et que je crée ensuite les principales requêtes SQL à la main, est-ce que ça suffit à régler les problèmes de perf ?

Si quelqu'un peut m'expliquer ou m'orienter vers de la doc je suis preneuse !

Avant de vouloir définitivement supprimer l'orm essai le. Peut être que ça conviendra à ton besoin.

Coté performance , c'est le mappage qui est généralement coûteux en ressource pas la création de requêtes (qui à peut de chose prêt seront les même que celle que tu vas écrire).

Souvent quand tu demandes une liste de données , un ORM va te retourner une liste d'objet alors qu'un tableau aurait suffit dans 90% des cas. Du coup tu te bourre un mappage pour chaque élément de la liste juste avoir le plaisir de faire $machin->gettruc() au lieu de $machin['truc'];

Citation:

---

"pas d'ORM" je suis d'accord. Par contre, je n'ai aucune idée de comment organiser mon code dans ce cas

---

Ba une classe "model" qui représente ton objet équivalent à ta table et une classe "modelsql" dans la quelle tu écrieras tes requêtes sql avec PDO et qui potentiellement pourra te retourner des instance de "model".

Je vois pas la difficulté de pas utilisé d'orm en fait :/

Merci pour ta réponse.

En fait j'essayais de recréer toute seule un ORM. Parce que pour moi qui disait Orienté Objet disait mappage des classes.

Suivant les tutos/forums j'ai trouvé des gens qui mettaient en place des Repository, Managers, DAO, Services... Et je n'arrivais pas à comprendre à quoi ça correspond ni les relations entre tous ces "trucs".

En ce qui concerne l'ORM, j'ai peur de perdre la main sur le code (difficulté à débugger à cause de la boite noire) et des perfs. Sinon j'aurais foncé droit devant !

Tous les ORM ont des perfs différentes

Extrait d'un précédent benchmark:
Soit une base de donnée avec 100 000 entrées dans une table article
l'outil time (linux) utilisé 10 fois sur une page listant dans un tableau html ces 100 000 articles

Les résultats:
sans framework ni orm: entre 0m0.032s et 0m0.041s
ORM de Zend framework: entre 0m16.817s et 0m19.180s
ORM du mkframework: entre 0m3.495s et 0m3.648s

Source: http://www.developpez.net/forums/d12...on-par-milieu/

Ne le prend pas mal imikado mais tu viens systématiquement prêcher pour ta paroisse ce qui me pousse à relativiser tes interventions ;)

Désolé, j'essaie de promouvoir comme je peux, en prenant des exemples objectifs, des benckmarks, tests de sécurité, analyse sonar... :)

Mais retenez surtout que tous les ORM ne se valent pas au niveau performance, que ce soit le mien, celui de zend ou celui de Jelix ;)

Le meilleur ORM c'est ......PDO, après tout le reste sera toujours plus lent.

Doctrine et Zend_DB étant les plus lourd à mon sens (mais les plus développé aussi :) ).

Après celui de imikado à l'air sympa....mais tu en trouveras pléthore sur le net.

Oui mais PDO n'est pas un ORM mais plutot un DAO

l'ORM permet de gerer ses enregistrements en base de donnée comme des objets:

Code:

---

1 2 3 4

$oArticle = new Article(); $oArticle->titre = "mon titre"; $oArticle->save();

---

Merci ;)

Il ne faut pas oublier Doctrine non plus ;)

PDO m'a l'air plus intéressant (on garde une couche entre le modèle et la base) mais du coup je ne comprends pas trop l'intérêt des ORM.
Pour des petits projets ils sont "inutiles", pour des plus gros ils ne tiennent pas la montée en charge... J'ai l'impression qu'ils ne sont pas adaptés au contexte professionnel :koi: Et s'il faut le tester pour voir, je ne voudrais partir en laissant un truc infame à refaire qui aura planté une fois en prod...

Ne mettez pas tous les ORM dans le même panier, tous ne sont pas des usines à gaz...

J'ai découvert le monde des ORM il y a 5-6 ans en découvrant à l'époque Symfony beta 1.0 avec propel à l'époque

Effectivement c'etait leger à écrire en php mais lourd et gourmand à executer (le modèle de classe factory/row etait trop lourd)
Ensuite ils sont passé à Doctrine plus léger

Entre temps j'ai travaillé avec Zend Framework (d'où les benchs) qui est effectivement lourd et peu performant

Entre temps, et parallèlement (mise en ligne en 2009) j'ai développé mon propre framework en essayant de ne pas reproduire les inconvenients que je voyait sur les autres (notamment les performances et la sécurité)
Et j'ai trouvé le bon compromis entre un ORM confortable, une maintenabilité simplifiée (avec des requetes clairement écrites) et des performances acceptables ;) (benchmarks à l'appui)

Mais sinon pour revenir au débat: pourquoi utiliser un ORM et pas simplement pdo ?

1. généralement un ORM s'appuie sur une DAO qui permet de se connecter de manière transparente à beaucoup de bases de données différentes (mysql/sql server/oracle sqllite...) et pdo n'est pas disponible forcement pour tous les sgbd
2. la maintenabilité/l'organisation
3. les performances (nombres de connexions actives...)
4. le confort à utiliser (on manipule des objets simplement)

Pourquoi ne pas utiliser simplement PDO si vous etes sur d'utiliser tel SGBD ?

Prenons pour exemple une application où vous utilisez mysql et 4-5 tables
Vous allez mettre toutes vos requêtes ou ? dans chaque fichier php ? (vous oubliez le MVC et ses avantages :( )
Imaginons que vous fassiez un compromis dans ce cas la: un fichier php qui regroupe toutes les requetes sql ? avec des noms de fonctions plus ou moins long ? selectAllArticles(), selectAllAuteur()...
Vous vous dites oui je vais faire un fichier php par table (article,auteur, categorie...)
Dans chaque fichier vous n'allez pas réinventer la roue mais appeler une fonction de connexion PDO (vous n'allez pas dupliquer N fois ce bout de code: DRY*)
Et vous choisissez de retournez en PDO plutot des objets que des tableau "FETCH_OBJ" (plus pratique)
vous êtes petit à petit en train de construire votre propre pseudo ORM ;)

Un exemple simple de confort de l'ORM:
si à plusieurs endroits de votre site vous devez mettre à jour plusieurs champs différents de votre article

En sql pure, vous aurez N requetes : une pour mettre à jour le titre, une autre pour le resumé, une autre pour le nombre de vues...

Code:

---

1 2 3 4

'UPDATE article set titre=? Where id=?',$titre,(int)$id 'UPDATE article set nbVues=? Where id=?',$nbVues,(int)$id 'UPDATE article set resume=? Where id=?',$resume,(int)$id

---

En ORM c'est bien plus flexible (pas besoin d'écrire chaque type de mise à jour ;) )

Code:

---

1 2 3 4 5 6 7 8 9

$oArticle->titre=$titre; $oArticle->save();   $oArticle->resume=$resume; $oArticle->save();   $oArticle->nbVues=$oArticle->nbVues+1; $oArticle->save();

---

*DRY Don't Repeat Yourself

Citation:

---

Envoyé par Shiho

) mais du coup je ne comprends pas trop l'intérêt des ORM.
Pour des petits projets ils sont "inutiles",

---

Au contraire, je trouve que pour de petit projet, l'ORM est vraiment bien, cfr au dessus de mon post.

C'est quand tu es en recherche de perf sur de gros site et de grosse requête que l'ORM montre ses limites.

Je travaille comme ceci suivant les projets :

Petit projet : Doctrine\Dbal ou Orm du Framework (Laravel - Fuelphp)
Moyen Projet : Doctrine ou Orm du Framework (Laravel - Fuelphp)
Gros Projet : Uniquement PDO.

Comme je ne travaille pas en multi base, je me permet donc le PDO, que je trouve plus souple que le driver spécifique.

Pour compléter ce que dit Imikado, ORM est une expression trop globale qui recouvre différents types d'utilisation.

Si tu programmes de façon procédurale, ça ne sert à rien de passer par un Orm. mais si tu codes en objet, il faudra bien à un moment que tu fasses la correspondance entre tes objets et tes tables. Et dès ce moment-là, tu fais de l'ORM.

Après, les ORM ne sont ni la solution miracle universelle, ni une solution bancale inutile pour des petits projets et insuffisante dans un contexte professionnel.

Déjà, et même si Java n'est pas php, tous les utilisateurs d'Hybernate et autres frameworks ORM dans tous les languages sourient en entendant que les "Orm ne sont pas adaptés au contexte professionnel". Les ORM ont été inventés dans un contexte professionnel.

C'est toujours une question de rapport entre coût de développement et coût d'utilisation. Qu'est-ce qui coûte plus cher, écrire soi-même son propre ORM (puisque on est obligé de le faire si on fait de l'objet), ou compenser la perte de performance éventuelle avec une stratégie de cache, voir en rajoutant de la puissance brute, vu avec le faible prix des serveurs et la facilité à ajouter des instances supplémentaires aujourd'hui pour les VPS? A moins que tu ne développes pour Facebook ou Amazon, cela va de soi.

Sans compter évidemment que tous les développeurs ne sont pas des DBA, donc il n'est pas sûr que la solution maison soit plus optimisée que celle proposée par l'ORM.

Citation:

---

Envoyé par MaitrePylos

Comme je ne travaille pas en multi base, je me permet donc le PDO, que je trouve plus souple que le driver spécifique.

---

Juste par curiosité, qui connait un développeur web qui ait déjà travaillé en multibase ou qui a changé de base en cours de route? (A part les développeurs de framework ou de CMS naturellement).

L'argument de l'abstraction du type de base est souvent donnée pour PDO ou les ORM, mais concrètement qui se sert de cette possibilité? Je suis réellement curieux de savoir si quelqu'un en a déjà tiré partie (et si ça s'est passé sans douleur).

Ca m'est arrivé une fois, mais c'était un autre contexte: je developpais en wamp (en local sur ma machine) et à la livraison en production j'ai livré sur un serveur qui communiquait avec une base sql server ;)

Mais effectivement, en production c'est plus que rare :)
Car il ne faut pas oubliez que lors d'une migration de sgbd, il faut réecrire certaines requetes qui utilisent une syntaxe propre au SGBD (exple avec les limites)

Merci pour ces échanges. :ccool:

J'avoue que ceux sur le post des Généralités sur les ORM m'avaient franchement refroidis. Effectivement j'ai utilisé un ORM quand j'ai développé en java mais d'une part c'était imposé, d'autre part je ne sais pas si le même choix aurait été fait pour un "vrai" projet (c'était un projet étudiant). Et à vrai dire, j'ai découvert qu'il y avait un choix à faire uniquement en parcourant les tutoriels et forums.

Je ne développe ni pour Facebook, ni pour Amazon d'ailleurs :mrgreen:

Bien vu imikado pour la fonction de connexion PDO et les résultats en fetch_OBJ, c'est ce qui est au programme si j'abandonne l'ORM.

Merci du débat, ça m'a donné l'idée d'en faire un billet : http://blog.developpez.com/ducodeetd...l-les-utiliser ;)

J'ai pu voir que Yii était pas mal performant quand même ;)