Même en utilisant un ORM, dire que SQL ne sert à rien c'est de la connerie...Envoyé par marc.collin
Surtout pour "tester" en direct sur la base c'est toujours utile de connaitre SQL
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Même en utilisant un ORM, dire que SQL ne sert à rien c'est de la connerie...
Surtout pour "tester" en direct sur la base c'est toujours utile de connaitre SQL
c'est justement mon point de vue et je suis bien content d'avoir une plusieurs cours sur le sujet.
"Êtes-vous pour ou contre les ORM ?" Pourquoi pour ou contre ?
Le choix de la méthode de persistance s'impose souvent par le contexte, ou par des décisions de l'entreprise prise dans le passé.
Pour un même projet, il peut y avoir plusieurs applications qui n'utilisent pas toutes les mêmes méthodes de persistance. Le temps fait son œuvre.
Je n'ai pas encore rencontré ce choix binaire...
Globalement, c'est toujours une question de besoin. Si on veut obtenir de bonnes performances, un framework de persistance comme MyBatis me parait bien plus approprié pour simplement prendre en charge la plomberie. Un ORM peut être intéressant si on veut se laisser la possibilité de changer de SGBD, mais c'est loin d'être le cas général. Autrement, un ORM apporte autant de complexité qu'il en supprime, donc à quoi bon ?
Quel complexité ???
Les ORM remplacent une tâche fastidieuse mais maitrisée, par une abstraction permettant un développement plus rapide sur des schémas simple, mais qui, comme toute abstraction, ajoute un lot de notion à appréhender pour avancer (Lazy/Deferred/Eager loading, etc) et peut également se révéler contre-productif, voire casse-gueule sur des schémas complexe.
Ca dépend quel ORM tu utilises....
Un EDM sur .Net pour faire un truc pas compliqué c'est les doigts dans l'nez...
Je précise que je ne connais pas les ORM de .NET, je n'ai d'expérience qu'avec doctrine (php) et hibernate (java).
C'est bien ce que je dis, pour faire un truc simple d'accord, mais dés que ça touche à des trucs plus compliqué et/ou à une forte volumétrie, faut avoir une très bonne connaissance de l'outil pour arriver à quelque chose.
Je plussoie Traroth2 de bon coeur cette fois. Le multi-sgbd est rarement quelque chose qu'on nous demande et ça veut aussi dire se passer de tout ce qui est trop spécifique au niveau BDD.
J'irai même plus loin, je ne pense pas que l'utilisation d'un ORM garantisse qu'on puisse changer de SGBD les yeux fermés à moins d'avoir une très bonne grosse suite de test sur chacune des DB visées.
Pour ma part, j'ai abandonné hibernate à cause des sentiments de perte de maîtrise qu'il nous procurait. Nous avons utilisé mybatis, puis nous passons petit à petit à JOOQ (Un DSL SQL pour java) car il nous apporte les mêmes avantages que mybatis mais avec une meilleure protection contre la régression.
Je suis pas contre un ORM dans le cas où l'on est souvent amené à manipuler des graphes complexes, cependant l'utiliser efficacement est difficile, parfois plus que le problème qu'on essaie de résoudre avec. Donc pour ma part, j'opte pour un simple mapper qui m'épargne le plus pénible de JDBC, je code plus de choses à la main mais les performances sont excellentes, optimiser mes chargements est facile et ma maîtrise des interactions avec la BDD est totale. Pas de bidouillage de bytecode, pas de magie noire, pas de proxys qui explosent à la figure quand on les sérialise. Ca me va très bien.
Je reconnais les services rendus par ces outils mais parfois, aller au plus simple et sortir avec un truc facile à comprendre et à débugger quitte à coder plus, c'est une bonne solution. De toutes façons celui qui utilise un ORM juste pour ne pas avoir besoin de bien connaître le SQL, il est sûr de se vautrer.
Première fois que j'entends parler d'ORM
Cela dit, DAL, BLL, unit tests je connais.
Rem: .net developer
C'est vrai que NHibernate et LinqToSql n'existent que depuis 4 ans....... (et même 6 pour NHibernate 1.0).Première fois que j'entends parler d'ORM
Cela dit, DAL, BLL, unit tests je connais.
Rem: .net developer
Le gros avantage d'un ORM au sens hibernate ou Ebean, je pense que c'est surtout de pouvoir manipuler facilement des graphes.
Mapper une collections de POJO assez basique ayant une relation OneToOne et 2 relations oneToMany, du Style un SPECTACLE qui a N SPECTATEURS, N ORGANISATEURS et qui a UNE VILLE, ben ça vous prendra facilement 200 lignes de code en JDBC si vous voulez avoir tout cela dans de jolis graphes.
Avec un ORM bien utilisé, c'est facile de charger SPECTACLE et VILLE avec un join et le reste avec des sous-requêtes.
Si sur ce même graphe vous voulez laisser un autre traitement supprimer ou modifier des spectateurs et ensuite re-persister le tout, ça demandera pas mal de boulot avec plein de booléens pour le dirty-checking plus garder les références des ID qui ont été supprimés pour envoyer le bon DELETE qui va bien.
Après c'est un débat au cas par cas de savoir si ce genre de modif constitue une action métier que le pojo peut proposer directement ou s'il faut passer par un service dédié. Mais dans tous les cas, faire cela à la main ce sera du boulot.
Sans ORM, avec des outils comme active record, jooq, ou même du pur jdbc, la plupart du code CRUD peut être écrit voire généré facilement.
Malheureusement tout ce qui est mappage multi-table vers graphe est assez difficile à réaliser et l'absence de lazy loading peut gêner lorsqu'on veut un graphe partiel sans vouloir dupliquer toutes les classes impliquées (dans le sens où on ne peut pas accepter de balader des demi-objets, chose extrêmement casse-gueule par nature).
Tiens mais j'avais pas dit que j'utilisais pas d'ORM moi justement? Ben oui, la raison est là : je n'ai pas ou presque pas de besoin en matière de chargement de graphe, presque toutes mes tables servent à de la trace ou de la statistique, pour les autres un pojo qui mappe une table 1:1 est suffisant. En plus lorsque je charge des collections, c'est généralement du gros (10000 lignes) donc je veux surtout pas de trucs invisibles (cache).
Voilà, c'est une pure question de besoin.
Simple question? Les BDD object , ça en est ou? ça permettrait justement de se passer des ORM sans sacrifier les performances non?
En php, on a PDO c'est déjà pas mal
Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
Mes cours/tutoriaux
Personellement, les 2 seuls cas pour lesquels je n'utilise pas un ORM
- Si l'aspect performance ne me laisse pas le choix
- Si jai seulement quelque requete simpliste a faire alors je considere que faire la configuration et un 'mapping' serais probablement une perte de temps. Ajouter une librairie et toute ses dependances seulement pour 1-2 requetes... un peu tordu.
sinon moi et hibernate on est de bon amis
Justement, si tu n'as jamais eu l'occasion de travailler sur des projets un tant soit peu sérieux (ex: des applications connectées aux marchés boursiers avec des transactions dans tous les sens) pourquoi tu te permets de donner ton avis ?
Et comme si cela ne suffisait pas, tu as l'outrecuidance de traiter certains de troll à mots à peine couverts et de sous-entendre qu'ils n'y connaissent rien... (là, c'est carrément se moquer du monde !)
Pas besoin d'être un expert en SQL pour faire des choses assez puissantes avec (il est bien sûr nécessaire de connaître les bases, mais il faut pas déconner non plus : c'est pas inhumain de connaître la différence entre un INNER, un OUTER et FULL join...).
C'est seulement quand les projets deviennent un peu sérieux (le genre de projet sur lesquels tu n'as, de ton propre aveu, jamais eu l'occasion de travailler) qu'on a besoin de regarder plus profondément dans les détails techniques du SGBD.
Si on a la chance d'avoir un collègue DBA (dans les petites entreprises, ce n'est pas toujours le cas et les développeurs jouent de rôle de factotum pour tout ce qui est ressources IT) c'est à ce moment qu'il faut se tourner vers lui pour discuter de son problème (et dans le pire des cas, la développeur et le DBA tombent d'accord : c'est l'architecte qui a pondu une abomination et maintenant il faut faire avec et bidouiller pour que ça ne plante pas trop).
Mais bon, quand on atteint ce niveau, c'est clair que ça ferait déjà longtemps que les ORM auraient été complètement à la ramasse...
Oui, les ORM ont leur utilité, au même titre que tous ces IDE qui permettent de faire du RAD (Rapid Application Development).
Ce qui m'a toujours amusé dans l'acronyme "RAD", c'est que cela ne veut pas dire "Développement d'Applications Rapides (comme on pourrait le penser de prime abord), mais "Développement Rapide d'Applications". Et dans les faits, c'est surtout: "Développement Rapide d'Applications (souvent très lentes et pas forcément faciles à maintenir)".
Et dans certains cas, ça se traduit par l'émergence d'un nouveau cycle de développement, que j'appelle "le cycle en 2 temps", malheureusement de plus en plus en vogue:
1er temps:
- l'entreprise exprime un besoin, elle fait un appel d'offres
- un consultant arrive et propose sa solution
- le consultant fait du RAD et respecte les délais
- le client est content, le consultant touche son gros chèque
- on met la solution en prod
2ème temps:
- au bout d'un certain temps d'exploitation, les problèmes de volumétrie/charge apparaissent
- on fait appel à un "spécialiste" pour corriger les défauts de "cette grosse m**** d'application" (dixit les utilisateurs)
- au bout d'un moment (3 ou 4 entreprises où on retrouve le même genre de problème), le "spécialiste" en a ras le c*l de devoir essuyer les m***** de ces consultants à la c*n
J'ai volontairement mis le terme "spécialiste" entre guillemets. En fait, ce qui en fait "spécialiste", c'est qu'il sait se retrousser les manches plutôt que d'utiliser des outils pour gamins censés lui mâcher le travail...
Il existe une variante, qui est le cycle en 3 temps. C'est la même chose que le cycle en 2 temps, mais avec une extension:
3ème temps:
- on sous-traite les évolutions du système dans un pays du tiers-monde où les gens s'en fichent parce qu'ils sont payés au lance-pierre pour travailler sur des applications où tout le monde a jeté l'éponge depuis longtemps
- on demande au dernier spécialiste en place de faire un "transfert de connaissances"
- si ce n'est pas déjà fait dans le 2ème temps (des raisons personnelles qui l'ont contraint à rester), le spécialiste se casse en disant à tout le monde d' "aller se faire ***** avec un ***** pendant qu'un ****** vous ***** le *****... " (utilisez votre générateur d'insultes préféré pour remplir les blancs)
Donc oui, les ORM et autres outils de RAD ont leur utilité : lancer la première phase du cycle en 2 ou 3 temps (c'est-à-dire pondre rapidement des applis, toucher son gros chèque et aller f**tre sa m***** ailleurs avant que les choses ne devennent un minimum sérieuses et que l'appli ne vous explose à la g*****).
Cordialement,
P.
"On en a vu poser les armes avant de se tirer une balle dans le pied..."
-- pydévelop
Derniers articles:
(SQL Server) Introduction à la gestion des droits
(UML) Souplesse et modularité grâce aux Design Patterns
(UML) Le Pattern Etat
Autres articles...
@pcaboche
joli post, ça sent sacrément le vécu tout ça, dis donc...
Je ne vais pas me la jouer Mireille Dumas, mais tu devrais consulter pour te faire du bien. Tu ferais moins de cauchemarsidée de groupe : les informaticiens anonymes
Il ne faut pas mettre tous les ORM dans le même panier.Donc oui, les ORM et autres outils de RAD ont leur utilité : lancer la première phase du cycle en 2 ou 3 temps (c'est-à-dire pondre rapidement des applis, toucher son gros chèque et aller f**tre sa m***** ailleurs avant que les choses ne devennent un minimum sérieuses et que l'appli ne vous explose à la g*****).
Tous n'affichent pas les mêmes performances (cf posts précédents)
Je préconise l'écriture des requêtes en SQL dans les classes modèles
Cela permet:
1. De séparer et centraliser les requêtes (un des avantages du MVC)
2. Gagner en performances et en transparence (permet facilement de switcher vers des vues si nécessaire)
3. Identifier les paramètres des requêtes (plus facile à sécuriser)
Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
Mes cours/tutoriaux
Un projet sérieux n'est pas forcément un projet de type boursier (bien au contraire, donner les moyens à des petits rigolos de créer des crises boursières, est ce bien sérieux ?
Tout projet donnant du boulot et à bouffer peut être considéré comme sérieux....
Pour le reste, tu pars dans un blabla qui s'éloigne un peu trop du sujet dans le sens ou à part montrer à quel point tu prends les gens de haut, te considère comme meilleur parce que n'utilisant pas (ou ne voulant pas) d'ORM...rien que pour ça, j'estime que tu es loin d'être sérieux et professionnel....
A défaut d'avoir un rasoir tu l'auras été
Répondre avec citation
Partager