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
Oui
Non
Pas d'avis
Discussion :
pour les fonctions les plus basiques oui...Envoyé par max2148
chaque bd a des types de données différentes et des fonctionnalités différentes qui ne sont pas nécessaire pris en compte par un orm, par exemple un hstore de postgres n'existe pas dans les autres bd... pour pouvoir l'utiliser dans jpa, beaucoup de code a été nécessaire pour que ça puisse fonctionner
Valider ce que l'orm génère comme requête.... je n'ai pas compris.
Ce que je montre là c'est la couche controller, ensuite bien entendu tu as ce qui se passe derrière ces fonctions qui fait appel à l'orm, et bien entendu il y a la facilité de traiter les données retournées, notamment pour les relations.
Si, dans SQL Server via les tables In Memory et l'indexation ColumnStore….
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
J'utilise moi-même Hibernate, et je vois des avantages et inconvénients dont personne n'a parlé.
Ce qui me manquerait le plus sans Hibernate, ce sont les chargements paresseux. Un gain de performance appréciable, mais complexe à coder soi-même. Hibernate le fait automatiquement.
Ce qui ne me manquerait pas, ce sont les problèmes de compatibilité avec d'autres librairies. Hibernate utilise des proxies qui affolent les librairies utilisant l'introspection de code, par exemple Jackson. Dans le cas de Jackson il existe un plugin, encore faut-il le savoir.
En parlant de Jackson, celui-ci possède des fonctionnalités appréciables permettant au développeur de gérer manuellement les cas complexes. Ça manque à Hibernate, et contourner un bogue peut être difficile.
Un problème récurrent que je vois avec les ORM est la façon de les aborder. M. Bendersky semble attendre de l'ORM qu'il permette de s'abstraire entièrement de la base de données sous-jacente et de traiter les données comme si elles étaient en mémoire vive. C'est trop en demander. Les ORM permettent d'économiser du code répétitif, point. Ils ne permettent absolument pas de ne pas savoir utiliser une base de données relationnelle et de ne pas utiliser SQL. Si on les utilise en connaissance de cause, ils sont très utiles.
Je dois admettre que mon expérience est à 99% sur Hibernate, donc d'autres développeurs ont peut-être une expérience différente.
1) En 25 ans de carrière je n'ai jamais rencontré un défenseur des ORM qui connaissait vraiment bien SQL.
2) "Les ORM sont bien pour les requêtes de base."
Ok admettons. Et? Dans la vraie vie d'un vrai système complexe les requêtes de base représente quelle partie du temps de développement par rapport à celui des requêtes complexes?
S'encombrer de la lourdeur d'un ORM pour ça...
3) Les ORM rendent indépendants de la base de données.
Non. Les ORM rendent dépendants de l'ORM !!
Ce qui est bien pire.
Ce qui rend indépendant de la base de données c'est justement SQL.
Si votre couche d'accès est complètement en SQL dans la DB (procédures stockées), vos couches d'accès (qui peuvent être multiples!) sont indépendantes et interchangeables!
3A) Oui mais quid changement de base de données?
Dans la vraie vie changer de base de données se passe moins souvent que le changement de technologie qui s'addressent à la DB.
Et faire passer du SQL d'une DB à l'autre, même si ce n'est pas automatique n'est pas la fin du monde (de DB2 windows à oracle en 2001 à DB2/400 en 2003 à SQL Server en 2016. Sans souci.
Un peu comme les gens qui considèrent que coder avec autre chose que VIM est une hérésie...
C'est sûr que quand on a 25 ans d'expertise dans un domaine, et qu'on a arrêté de se tenir à jour niveau technos parce qu'au bout d'un moment marre quoi, il faut bien justifier cette expertise et le chèque qui va avec.
Je sais pas. Peut-être que tu as raison que je devrais arrêter de me tenir à jour.
En attendant toute l'interface est en vue.js - asp.net core 3 preview 5 - les appels à la DB passent les rows aux procédures stockées en JSON en SQL Server 2016, etc, etc, ...
Mais bon tu as raison c'est du vieux brol.
Vivement la retraite.
Alors là, que dire de plus, tout est dit. Je confirme complètement via ma aussi très longue expérience sur plusieurs plateforme (J2EE et M$) : je n'aurais pas dit mieux.
J'ai toujours galéré avec les ORM et je pense qu'il n'y a aucun sens à vouloir transformer un modèle relationnel en modèle objet et inversement.
Plus haut ça parle de conception de base de données. Un ORM prend également en considération sa consistance.
Par exemple, une table de droits, une table d'utilsateur et une table affectant les droits d'un utilisateur sur un autre (ce serait des groupes ou peut n'importe, ça ne changerait rien). Lorsqu'un utilisateur 1 a des droits sur un utilisateur 2 et que l'utilisateur 2 en a sur l'utilisateur 1. Par exemple "tu as le droit de voir mes trucs et moi j'ai le droit de voir et modifier tes trucs". L'ORM va vite partir en référence circulaire.
Et là il faut jouer avec du depht ou rendre des propriétés protégées pour ne pas les inclure mais dans un autre cas on en aura besoin et ça part très vite en bricolage.
Pour les mises à jour aussi ce n'est pas terrible. Il faut aller chercher un objet, modifier ce que l'on a besoin de modifier, puis l'enregistrer. Ça en fait des échanges alors qu'un UPDATE est bien plus simple.
Pour des requêtes un peut complexe, soit on passe son temps à détourner l'ORM pour réutiliser son pool de connectivité interne, soit il faut en créer un autre, donc deux gestion à mettre en place.
Aussi, il n'y a pas d'ORM qui sort du lot, donc aucune capitalisation de compétence / connaissance à en retenir, donc aucun intérêt de dire qu'on a 3 ans d'XP sur tel ou tel ORM. Mieux vaut dire que l'on en a 3 en SQL.
Donc la promesse de gagner du temps en code produire par l'abstraction de ce qu'il y a derrière ne peut être tenue. Au contraire ça ne fait que rendre les choses plus obscures, donc plus coûteuses.
Avoir des gros pavés SQL dans le code n'est pas génial non plus, car on veut aller à l'essentiel de ce que ça fait et pas comment ça le fait. Ce que j'ai fait c'est mettre mes requêtes SQL dans des fichiers avec un petit loader qui fixe les paramètres nécessaire pour charger le fichier et exécuter la requête. Ainsi le code reste propre, lisible et avec ai milieu truc léger, tout con et réutilisable.
Ce que j'aimerais c'est approfondir GraphQL, avec génération et surveillance du schéma, ça ferait déjà un truc en moins à penser / maintenir. Ce qui me freine c'est qu'ils ont leur propre syntaxe de requête à mettre dans des chaînes de caractères. Ce serait du JSon permettant ainsi d'utiliser les linter, d'échapper les variables et ainsi de garder un code propre, ça serait super bien. Après je n'ai que survolé, j'espère avoir prochainement le temps de m'y intéresser de plus prêt.
Toujours est-il que ce qui est sûr, c'est qu'un dev qui manipule de la data doit savoir comment elle est organisée pour être efficace dans sa manipulation
"Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero
Là tu ne fais jamais que bricoler une ébauche d'ORM simplifiée...
et génère des requêtes supplémentaire
C'est assez drole ce genre de news car on peut sortir a peu pres n'importe quel argument, sans etude, sans contexte et essayer d'en faire une generalite.
Etant donne que chaque orm a ses specificites, il faudrait savoir de quoi l'on parle: un micro orm type dapper, ou un monstre type hybernate/jpa/entity framework ?
Meme question pour les sgbd, on attaque pas de la meme maniere un sqlite qu'une base oracle.
Mais avant ca il faut parler du scope du projet, du contexte, des contraintes et fonctionnalites, du volume de donnees.
Enfin il faut ajouter l'experience de l'equipe de dev, si c'est un projet long terme, le turnover de la societe et la politique de la boite.
Une fois seulement on peut commencer a parler choix et consequences:
- Utiliser un orm sur on projet .net core qui aura une duree de vie d'un an c'est correct.
- Si le projet consiste majoritairement a faire des imports de donnees csv, l'orm sera plus un frein qu'un apport.
désolé, pas vraiment la même chose...
Dans quel(s) langage(s) travailles-tu ?
En Python, en dehors des projets avec Django, je crois que c'est SQLAlchemy qui sort du lot.
Topic à troll ? ze relational-object impedance mismatch :;
Empreinte PGP - Je suis les règles de Crocker.
Bonjour
Pour moi, réponse de normand: tout dépend de la question à laquelle vous devez répondre.
Si vous devez développer une application qui doit interroger différentes bases de données, alors SQL est votre ami.
Vous devrez toujours interroger la même base de données en entreprise, alors un ORM peut être la solution.
J'étais beaucoup dans le premier cas à utiliser des requêtes SQL. Et je me rend compte qu'en réalité j'étais plus dans le 2ème cas: à taper toujours dans la même base mais finalement à recréer un miniORM. Alors, franchissons le pas. Pour une appli d'entreprise et de reporting, un ORM est parfait. Cela simplifie le développement et les performances ne sont pas impactées.
Néanmoins, j'ai opté pour un ORM concernant le développement d'un microservice. Et j'avais l'impression d'utiliser une bombe atomique pour tuer un moustique. Oui, des requêtes SQL eussent (corrigez moi si je me trompe) été mieux, mais j'avais aussi dans la tête un besoin d'évolution et de flexibilité et la souplesse d'un ORM n'est pas à remettre en question.
Just my 2 cents,
@++
GLDavid
Consultez la FAQ Perl ainsi que mes cours de Perl.
N'oubliez pas les balises codeni le tag
Je ne répond à aucune question technique par MP.
N'oublions pas que les coûts matériels pour rattraper une perte de performance sont pratiquement toujours mineurs par rapport à ceux engendrés par un code de mauvaise qualité qui nécessitera plus de maintenance.
Est-ce un problème de données ou d'application ? Rien compris à l'exemple.
Quel rapport entre des droits (dans une table) et une référence circulaire ? Là, c'est la requête, via ORM ou en SQL natif, qui est, pour rester correct, à refaire.
Bah non puisque l'on a le contrôle de la requête pour aller chercher ce dont en a besoin et surtout comment. Et ça n'a rien à voir avec le fait de chercher à transformer un schéma relationnel en schéma objet.
"Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero
Avec un ORM aussi tu peux avoir un contrôle total sur ta requête. Dans 95% des cas celui-ci n'est pas nécessaire, mais il existe.
Il faut arrêter avec les parodies d'informaticiens, la majorité de nos requêtes ce sont des requêtes simples, pas des monstres avec 10 jointures et 15 sous-requêtes.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager