Discussion :

[StringBuilder]

Pour mieux comprendre le point de vue que tu exprimes dans ce topic, pourrais tu STP décrire ta fonction actuelle et tes expériences personnelles avec les ORM ?

J'ai commencé l'informatique il y a maintenant 20 ans, à l'époque où les ORM étaient tout sauf monnaie courante.
A vrai dire, j'ai dû attendre au moins 10 ans avant de voir les premiers projets utilisant des ORM à proprement parler.

Initialement, je faisais des sites web, notamment eCommerce, puis j'ai glissé dans le monde de l'intégration ERP et CRM.
Depuis, j'ai une casquette de développeur qu'à temps très partiel.

A l'époque, de nombreuses solutions ERP et CRM en mode client lourd étaient capable de supporter 200 sessions utilisateurs et 1000 traitements concurrents sur des serveurs ayant 128 Mo de RAM et un bête processeur pentium 200 MHz, sur du réseau 10 Mbps et pourtant délivrant des temps de réponse de l'ordre du dixième de seconde.

Ensuite, est arrivée l'époque de la grande mode du Java et du XML… Ces solutions ont été réécrites, et on s'est retrouvé avec des fermes de 10 serveurs de quadri processeurs xeon 1 GHz avec 8 Go de RAM chacuns pour absorbler la même charge avec des temps de réponse décuplés (plus de 5 seconde de temps de réaction).

Depuis, les versions de couches ORM se sont succédées, les serveurs ont continués à augmenter en capacité, et on continue d'avoir des applications infiniment plus consommatrices et infiniment plus lentes.

La raison ? Simple : là où chaque écran déclenchait 2 ou 3 requêtes SQL convenablement écrites, maintenant on a droit à des dizaines, si ce n'est parfois des centaines de requêtes, parfois complètement débiles et redondantes. On a beau passer à des réseaux 10 GBps, le temps de latence de 10 requêtes sur une machine ultra moderne est toujours plus grand d'une seule sur un vieux pentium 200 en 10 MBps. C'est comme ça.

Côté développement avec des ORM, j'en ai pour ainsi dire pas fait. A chaque fois que j'ai commencé à écrire des débuts de programmes, je me suis rendu à l'évidence après quelques heures : l'empilement des couches, et l'abstraction totale de la base de donnée produit des requêtes multiples et inutiles. Au mieux, on va pallier une partie des défauts en mettant en place du cache applicatif, qui va bouffer 4 Go de RAM juste pour afficher une page de temps en temps.

-- Edit : ah, oui, et autant mon expérience des ORM en tant que DEV ne va pas chercher bien loin, autant mon expérience des développeurs qui n'ont aucune idée de ce qu'est une base de donnée et le SQL s'est peaufinée sur 20 ans d'expérience…
Et visiblement, malgré la présence d'un ORM, une méconnaissance de base de ce qui se passe en base de données ne résout aucun des problèmes que j'ai pu constater.
1/ Faire 1 lot de 1 requête : je ne sais même pas si un ORM est capable de lancer plusieurs requêtes dans un même lot. Cela permet pourtant d'échanger avec le serveur en une seule fois.
2/ Faire 1 requête par information unitaire : à l'image de la réponse de deltree ci-dessous, cette pratique, pourtant cause d'un encombrement conséquent du SGBD est monaie courante.
3/ Faire des requêtes dans des boucles pour déterminer des données relatives à un résultat intermédiaire : si on ne demande pas à l'ORM de le faire, il ne fera pas la jointure, et ne saura en aucun cas comprendre qu'on fait de la merde quand on va rechercher à l'intérieur d'une boucle le nom de chaque produit d'une commande.

Et le plus grave dans tous cas, c'est qu'un ORM pousse le développeur à totalement ignorer la partie base de données. Par conséquent, outre la modélisation généralement hasardeuse, on se retrouve avec une mauvaise utilisateur de l'ORM lui-même, tout simplement parce que "c'est plus simple de faire des requêtes dans une boucle qui est dans une boucle dans une autre boucle". J'ai même vu du code où le développeur chargeait des millions de lignes pour calculer le total lui-même… l'explication "ben je savais plus comment on faisait la somme, alors là ça allait plus vite de faire comme ça que de chercher dans la doc".

en JPQL:

Code :

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

1
2
 
     Select city.coutry,city.type, count(city) from City c group by city.country, city.type;

ou pour le total de population :

Code :

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

1
2
 
     Select city.coutry,city.type, sum(city.population) from City c group by city.country, city.type;

Du reste je trouve que même en SQL on ne devrait pas tenter de transposer en colonne ce qu'on peut obtenir en ligne, globalement ce qu'on fait chaque fois qu'on utilise du "case when", on sort du paradigme SQL ensembliste standard.

Donc deux requêtes là où je n'ai besoin que d'une seule.
Et le double d'informations transitant sur le réseau pour la seconde, plus obligation de gérer un curseur et une boucle aussi bien côté serveur que client.

Sans oublier l'inconsistance des données : ici on parle de population de villes, ça bouge pas beaucoup.
Maintenant, dans une application de compta, du veux le total des débit et le total des crédits… si tu exécutes deux requêtes, tu n'as aucune garantie que personne ne passe une écriture entre des deux requêtes : tu te retrouves alors avec une balance déséquilibrée…
Reste alors à apposer un lock sur la table pour toute la durée d'exécution de tes multiples requêtes… avec tous les problèmes que cela implique. Bref : du code lent, buggé, et pour ainsi dire impossible à maintenir.

[SQLpro]

Mais c'est incroyable de lire et relire les mêmes banalités crasses sur le sujet. On n'utilise pas un ORM pour éviter d'avoir à apprendre le SQL, on utilise un ORM pour avoir du code propre, orienté objet, factorisé, maintenable

Je pense que vous devriez changer de pseudo… Sodium me parait un peu fade…. ayatollah me parait plus juste !

Vous oubliez une seule chose, la plus fondamentale… On ne créée pas des applications informatique pour le ravissement du développeur béat d'admiration devant le magnifique code qu'il vient de pisser… Mais pour satisfaire les utilisateurs….
Un utilisateur ne verra jamais votre code et s'en fou royalement. Mais il verra les temps de réponse…. Les recherches menées par IBM dans les années 70 (déjà) montrait que au delà de 3 secondes d'attente derrière un écran, un utilisateur considère qu'il y a un problème… et au delà de 7 secondes, que le bidule est cassé….
Avec l'accélération des demandes et le galop technologique, ces temps ce sont considérablement réduits… Et vous, vous en êtes à vous dire que ce qui est plus important que l'utilisateur, c'est que le code soit bien factorisé (donc encore plus de lignes, d'appel et de temps….), orienté objet (donc encore plus d'encapsulation, d'appel et donc de temps…).

Je crois que vous êtes tout à fait à côté de la plaque… En Provence, je vous voit tout à fait à votre place en temps que ravi de la crèche…

A +

[Sodium]

J'ai commencé l'informatique il y a maintenant 20 ans, à l'époque où les ORM étaient tout sauf monnaie courante.

Argument d'autorité sans aucun intérêt. Ce n'est pas tout d'être un vieux de la vieille, encore faut-il garder ses compétences à jour.

Côté développement avec des ORM, j'en ai pour ainsi dire pas fait.

Ah ben voilà, pourquoi ne pas avoir commencé par là ?

La raison ? Simple : là où chaque écran déclenchait 2 ou 3 requêtes SQL convenablement écrites, maintenant on a droit à des dizaines, si ce n'est parfois des centaines de requêtes, parfois complètement débiles et redondantes. On a beau passer à des réseaux 10 GBps, le temps de latence de 10 requêtes sur une machine ultra moderne est toujours plus grand d'une seule sur un vieux pentium 200 en 10 MBps. C'est comme ça.

La raison, comme je l'ai déjà dit, et comme le sait n'importe quel développeur compétent, c'est que rajouter du temps de développement coûte TOUJOURS plus cher que de rajouter de la puissance. Les applications ne font pas non plus la même chose qu'il y a 20 ans. En partant comme ça on aurait du en rester au cartes perforées, là on n'avait besoin que de quelques ko de vitesse processeur...

A chaque fois que j'ai commencé à écrire des débuts de programmes, je me suis rendu à l'évidence après quelques heures : l'empilement des couches, et l'abstraction totale de la base de donnée produit des requêtes multiples et inutiles.

Traduction : du haut de mes 20 ans d'expérience (et de grande expertise), j'ai essayé et j'ai trouvé tout de suite que c'était nul alors j'ai arrêté et ceux qui utilisent ça sont des cons.

Bref, qu'on peut conclure sur le "les ORM, je n'en ai pour ainsi dire pas fait". Pourquoi intervenir dans le débat dans ce cas ? Moi je ne me permettrais pas de venir déblatérer des inepties si je ne faisais pas régulièrement du SQL...

Vous oubliez une seule chose, la plus fondamentale… On ne créée pas des applications informatique pour le ravissement du développeur béat d'admiration devant le magnifique code qu'il vient de pisser… Mais pour satisfaire les utilisateurs….

Vous oubliez une seule chose, la plus fondamentale : dans le monde professionnel, avant de créer une application pour les utilisateurs, on la créer pour un donneur d'ordre. Quand c'est un client, il veut le minimum de jours/homme pour réaliser la chose et ça passe obligatoirement par l'organisation du code en librairies facilement réutilisables. Quand le client est directement le patron de la boîte (c'est mon cas), il veut à la fois le minimum de jours/homme pour développer le truc mais surtout le minimum de besoins humains pour la maintenir une fois qu'elle est en production. Un ORM c'est du code objet, clair, standardisé et centralisé dans un seul et même langage, donc du gain de temps, donc du gain d'argent, beaucoup plus que celui induit par d'éventuels pertes de performances. Je vous laisse faire le calcul de ce que l'on peut rajouter comme serveurs pour le coût mensuel d'un développeur supplémentaire.

[SQLpro]

… dans le monde professionnel, avant de créer une application pour les utilisateurs, on la créer pour un donneur d'ordre. Quand c'est un client, il veut le minimum de jours/homme pour réaliser la chose et ça passe obligatoirement par l'organisation du code en librairies facilement réutilisables. Quand le client est directement le patron de la boîte (c'est mon cas), il veut à la fois le minimum de jours/homme pour développer le truc mais surtout le minimum de besoins humains pour la maintenir une fois qu'elle est en production...

En conclusion votre patron créé des application informatique pour son propre usage et se fout royalement des clients…. !

A +

[StringBuilder]

Argument d'autorité sans aucun intérêt. Ce n'est pas tout d'être un vieux de la vieille, encore faut-il garder ses compétences à jour.

Je ne faisais que répondre à vertex.3F qui n'avais posé la question.

La raison, comme je l'ai déjà dit, et comme le sait n'importe quel développeur compétent, c'est que rajouter du temps de développement coûte TOUJOURS plus cher que de rajouter de la puissance.

Totalement faux, et ce, pour tout un tas de raison dont voici quelques unes :
- Quand le développeur doit repasser 20 fois sur son code pour comprendre pourquoi à 9h30 le truc s'effondre (sans forcément trouver de solution pour y remédier), ça coûtera toujours plus cher que d'avoir passer 5 minutes de plus de temps en temps pour réfléchir à une solution plus performante mais un peu plus verbeuse ou complexe.
- Quand tu arrives aux limites des capacités du matériel SOHO, tu arrives à des sommes telles qu'il faudra quelques semaines de travail en équipe pour amortir l'achat de nouveau matériel plus performant (s'il existe)
- Quand tu commences à devoir mettre en place des solutions complexes de load balancing et de culstering pour résoudre des problèmes de performance, arrive vite à des sommes mirobolantes en termes de licences, sans compter la complexité du code pour gérer la concurrence.
- Administrer une ferme de serveurs demande bien plus de compétences (donc plus cher) et de temps récurrent que pour 2 ou 3 serveurs… je ne parle pas du plan de maintenance et du PRA.
- Le temps perdu par les utilisateurs peut rapidement se chiffrer en millions de manque à gagner

Les applications ne font pas non plus la même chose qu'il y a 20 ans. En partant comme ça on aurait du en rester au cartes perforées, là on n'avait besoin que de quelques ko de vitesse processeur...

Ca c'est le truc le plus débile que j'ai jamais lu.
Autant pour ce qui est du reporting et de l'analyse de données, il y a eu un bon énorme, autant pour tout ce qui est informatique de gestion, on a plutôt tendance à revenir sur la complexité mise en place au siècle dernier… dois-je te rappeler qu'il eu une époque où les marges arrières étaient légales, que chaque pays d'Europe avait sa propre monnaie ?
Un WMS fait toujours rigoureusement le même travail, une compta fait toujours rigoureusement le même travail, une paie aussi, une CRM aussi… Le volume de données aussi est relativement stable, mise à part les bases documentaires qui ont explosées.

[Sodium]

En conclusion votre patron créé des application informatique pour son propre usage et se fout royalement des clients…. !

C'te niveau de bêtise dans l'intervention. L'application se porte parfaitement bien du côté utilisateur avec un temps de réponse non perceptible

Totalement faux, et ce, pour tout un tas de raison dont voici quelques unes :

Ben oui... mais non, c'est une réalité objective, pas une opinion.

Quand le développeur doit repasser 20 fois sur son code pour comprendre pourquoi à 9h30 le truc s'effondre

Ce qui n'arrive pas quand le code est bien écrit, et il sera toujours mieux écrit avec un ORM

Quand tu arrives aux limites des capacités du matériel SOHO, tu arrives à des sommes telles qu'il faudra quelques semaines de travail en équipe pour amortir l'achat de nouveau matériel plus performant (s'il existe)

Tu confonds code pourri et code pas optimisé à 100%, ce qui est absurde. Tu opposes d'un côté un code 100% SQL rédigé par des experts ayant optimisé à la main chaque ligne de code et de l'autre du code comprenant un ORM rédigé par des bras cassés. On est très rarement du côté d'un pôle ou de l'autre.

Quand tu commences à devoir mettre en place des solutions complexes de load balancing et de culstering pour résoudre des problèmes de performance, arrive vite à des sommes mirobolantes en termes de licences, sans compter la complexité du code pour gérer la concurrence.

Ce qui est le cas de n'importe quel application prenant de l'ampleur et devant servir une large zone géographique...

Administrer une ferme de serveurs demande bien plus de compétences (donc plus cher) et de temps récurrent que pour 2 ou 3 serveurs… je ne parle pas du plan de maintenance et du PRA.

Oui, c'est pour ça qu'on a inventé les providers qui ne font que ça...

[deltree]

J'ai commencé l'informatique il y a maintenant 20 ans, à l'époque où les ORM étaient tout sauf monnaie courante.
A vrai dire, j'ai dû attendre au moins 10 ans avant de voir les premiers projets utilisant des ORM à proprement parler.


Ensuite, est arrivée l'époque de la grande mode du Java et du XML… Ces solutions ont été réécrites, et on s'est retrouvé avec des fermes de 10 serveurs de quadri processeurs xeon 1 GHz avec 8 Go de RAM chacuns pour absorbler la même charge avec des temps de réponse décuplés (plus de 5 seconde de temps de réaction).


La raison ? Simple : là où chaque écran déclenchait 2 ou 3 requêtes SQL convenablement écrites, maintenant on a droit à des dizaines, si ce n'est parfois des centaines de requêtes, parfois complètement débiles et redondantes. On a beau passer à des réseaux 10 GBps, le temps de latence de 10 requêtes sur une machine ultra moderne est toujours plus grand d'une seule sur un vieux pentium 200 en 10 MBps. C'est comme ça.

Côté développement avec des ORM, j'en ai pour ainsi dire pas fait. A chaque fois que j'ai commencé à écrire des débuts de programmes, je me suis rendu à l'évidence après quelques heures : l'empilement des couches, et l'abstraction totale de la base de donnée produit des requêtes multiples et inutiles. Au mieux, on va pallier une partie des défauts en mettant en place du cache applicatif, qui va bouffer 4 Go de RAM juste pour afficher une page de temps en temps.

-- Edit : ah, oui, et autant mon expérience des ORM en tant que DEV ne va pas chercher bien loin, autant mon expérience des développeurs qui n'ont aucune idée de ce qu'est une base de donnée et le SQL s'est peaufinée sur 20 ans d'expérience…
Et visiblement, malgré la présence d'un ORM, une méconnaissance de base de ce qui se passe en base de données ne résout aucun des problèmes que j'ai pu constater.
1/ Faire 1 lot de 1 requête : je ne sais même pas si un ORM est capable de lancer plusieurs requêtes dans un même lot. Cela permet pourtant d'échanger avec le serveur en une seule fois.
2/ Faire 1 requête par information unitaire : à l'image de la réponse de deltree ci-dessous, cette pratique, pourtant cause d'un encombrement conséquent du SGBD est monaie courante.
3/ Faire des requêtes dans des boucles pour déterminer des données relatives à un résultat intermédiaire : si on ne demande pas à l'ORM de le faire, il ne fera pas la jointure, et ne saura en aucun cas comprendre qu'on fait de la merde quand on va rechercher à l'intérieur d'une boucle le nom de chaque produit d'une commande.

Et le plus grave dans tous cas, c'est qu'un ORM pousse le développeur à totalement ignorer la partie base de données. Par conséquent, outre la modélisation généralement hasardeuse, on se retrouve avec une mauvaise utilisateur de l'ORM lui-même, tout simplement parce que "c'est plus simple de faire des requêtes dans une boucle qui est dans une boucle dans une autre boucle". J'ai même vu du code où le développeur chargeait des millions de lignes pour calculer le total lui-même… l'explication "ben je savais plus comment on faisait la somme, alors là ça allait plus vite de faire comme ça que de chercher dans la doc".

Désolé ,je ne cite pas tout, et votre expérience en SQL est intéressante, peu importe que vous n'en ayez pas en ORM on ne peut pas être spécialiste en tout.

MAIS

Tout votre post ressemble à une agiographie du SQL, et vous semblez déverser un nombre incalculable d'arguments pour exprimer le fait que selon vous les ORM ne fonctionnement pas.
Tout ceci ne ressemble pas un un débat argumenté, que retirez-vous de cette discussion?

Vous semblez avoir déjà votre avis, c'est ce qu'on appelle un biais de confirmation.

1/ oui on peux!
2/ Faire 1 requête par information unitaire : Oui on peut! voir ci-dessous
3/ Eh bien, il faur demander à l'orm de le faire, on peut faire de mauvaises requetes jpql comme de mauvaise requetes SQL!

Donc deux requêtes là où je n'ai besoin que d'une seule.

j'avais dis "ou" pas "et", Et voila en une seule
en JPQL:

Code :

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

1
2
 
     Select city.coutry,city.type, count(city), sum(city.population) from City c group by city.country, city.type;

En fait à chacun de vos arguments, je peux prouver qu'on peut bien faire en ORM, certes ça demande un investissement, de passer plus de 5 minutes et se dire "ça marche pas ce truc"
et parfois,parfois, très rarement, on a un cas au limites qui nous demande de repasser au pur SQL, mais ça l'ORM ne l'a jamais empêché.

Et le double d'informations transitant sur le réseau pour la seconde, plus obligation de gérer un curseur et une boucle aussi bien côté serveur que client.

n'importe quoi, on ne gère pas de curseur en ORM.

[deltree]

Mais c'est incroyable de lire et relire les mêmes banalités crasses sur le sujet. On n'utilise pas un ORM pour éviter d'avoir à apprendre le SQL, on utilise un ORM pour avoir du code propre, orienté objet, factorisé, maintenable

Je pense que vous devriez changer de pseudo… Sodium me parait un peu fade…. ayatollah me parait plus juste !

A +

Bien mais je ne juge pas la personne mais le propos,et celui-ci, ce propos de Sodium, me semblait pertinent , si on sortait de l'idée reçue que les developpeurs d'orm sont des buses en SQL, on gagnerais en clarté, et pour ce qui concerne le prosélitisme "ayatollah", j'en vois beaucoup sur les intervention SQL, beaucoup de poncif et d'idée reçues et peu de factuel.

Edit ajout de la quote "Sodium"

[Waldar]

À mes collègues anti-ORM, il y a quelques informations plutôt intéressantes dans les réponses de Sodium sur la lisibilité et maintenabilité du code applicatif.

Je pense qu'il vous manque une petite brique, c'est qu'un ORM va dans la majorité des cas en code applicatif plutôt bien construire une requête SQL (sur du code simple à moyen) dans le langage de programmation natif du développeur. C'est une souplesse que je trouve au final intéressante, et j'étais plutôt anti-ORM a priori.

Pour être complet, je retrouve ce phénomène sur les analytics. On n'est plus dans de l'application mais dans de l'analyse de données volumétrées.
Les data scientists sont en général plus à l'aise en R et Python qu'en SQL et souvent ils importent des gros dataframes sur leur poste en local ou sur un serveur avec beaucoup de RAM pour faire ensuite de la manipulation de données, parfois de simple sommes cumulées, moyenne, calcul écart types, ce qui est bien entendu contre performant car ce sont des opérations que les bases font très bien.

Avec une bibliothèque qui joue le rôle d'ORM et qui va traduire du code R / Python vers SQL, ça leur donne des possibilité de faire plus d'analyses, c'est performant côté DB et élégant pour le data scientist qui reste dans son environnement qu'il connaît le mieux.
Bien entendu, cette approche conserve une limite lié à la complexité des opérations effectuées, à partir d'un moment ils devront faire appel à des spécialistes du SQL.

[StringBuilder]

n'importe quoi, on ne gère pas de curseur en ORM.

Du moment que tu lis les données multi-lignes retournées par une requête, il y a forcément création d'un curseur côté serveur, et un curseur côté client.
C'est masqué par l'ORM, voir même par la couche d'accès aux données, mais ça existe.

Et c'est justement le travers des ORM : à vouloir tout masquer sous une pile de linge sale de couches et d'objets, on en arrive à ne plus savoir comment ça fonctionne derrière, et… produire une usine à gaz sans même s'en rendre compte.

[MaximeCh]

Et c'est justement le travers des ORM : à vouloir tout masquer sous une pile de linge sale de couches et d'objets, on en arrive à ne plus savoir comment ça fonctionne derrière, et… produire une usine à gaz sans même s'en rendre compte.

C'est la substance que je tire de ce topic : il faut un niveau monstre pour utiliser de façon éclairée un ORM : il faut maîtriser son middleware donc, plus son langage objet, le sql, le rapport entre POO et algèbre relationnelle, avoir une capacité d'abstraction infâme et planer à dix mille, mais aussi pouvoir aller mettre les mains dans le cambouis le plus noir dès que le besoin se fait sentir. La vie d'un bon développeur quoi. Mais bon pour la simplexité c'est pas gagné

[Sodium]

Un jour vous comprendrez peut-être que les ORM sont utilisés généralement sur de l'applicatif simple qui ne nécessite pas de faire des requêtes ultra-compliqué sur des millions de records et réaliserez que l'immense majorité de vos arguments n'a rien à faire dans la discussion. Peut-être

Les problèmes de performances, on les adresse quand on les rencontre, en partant du principe qu'on n'a pas une équipe de manches qui va faire n'importe quoi de A à Z (et là, ORM ou SQL, le résultat sera le même). Si votre application a besoin de gérer des dizaines de milliers d'utilisateurs simultanés, eh bien tant mieux, ça veut dire que votre business marche et qu'il est temps d'embaucher et plancher sur une application plus performantes. Si vous partez du principe que vous allez dès le départ avoir ces besoins et programmez une machine de guerre en conséquence, à moins d'un gros coup de bol, vous allez juste perdre de l'argent.

[deltree]

Du moment que tu lis les données multi-lignes retournées par une requête, il y a forcément création d'un curseur côté serveur, et un curseur côté client.
C'est masqué par l'ORM, voir même par la couche d'accès aux données, mais ça existe.

Et c'est justement le travers des ORM : à vouloir tout masquer sous une pile de linge sale de couches et d'objets, on en arrive à ne plus savoir comment ça fonctionne derrière, et… produire une usine à gaz sans même s'en rendre compte.

Eh bien tu le dis toi même, c'est masqué donc on n'est pas "obligé" de le gérer. (Tu ne peut pas t'empêcher d'ajouter des réflexions négative de type linge sale)
Je ne vois pas spécialement où est le problème: en SQL pur tu vas boucler de la même manière, les cas de perte de performance ne se passent pas à ce niveau la.(c'est pas du "SQL pur" du reste, on est obligé d'utiliser l'api du langage , en java le jdbc)

A la limite si tu évoque les problème de pagination pour limiter le débit réseau on les règle autrement justement.

[deltree]

C'est la substance que je tire de ce topic : il faut un niveau monstre pour utiliser de façon éclairée un ORM : il faut maîtriser son middleware donc, plus son langage objet, le sql, le rapport entre POO et algèbre relationnelle, avoir une capacité d'abstraction infâme et planer à dix mille, mais aussi pouvoir aller mettre les mains dans le cambouis le plus noir dès que le besoin se fait sentir. La vie d'un bon développeur quoi. Mais bon pour la simplexité c'est pas gagné

la "simplexité", néologisme volontaire?

En même temps j'aurais tendance à dire que s'il suffisait d'un tuto de 5 minutes pour maitriser le développement, j'aurais un peu honte de demander mon salaire.
Mairtiser une base de données, de sa conception, modélisation jusqu'au requetes, qu'elle soient SQL JPQL ou autre, ça demande un minimum de connaissance théorique, et un maximum d'expérience.
Combien de système pas normalisés et bancals j'ai pu voir, ça mettrais les Pro-SQL et les pro ORM d'accord, on ne fait pas n'importe quoi avec sa BDD.

[MaximeCh]

la "simplexité", néologisme volontaire?

Alain Berthoz n'est quand même plus très néo

[mermich]

Au final:

• Les bons devs utilisent des orm, tandis que les faibles d'esprit restent sur les requetes a la main ?
• ou c'est l'inverse ?

[Cincinnatus]

Au final:

• Les bons devs utilisent des orm, tandis que les faibles d'esprit restent sur les requetes a la main ?
• ou c'est l'inverse ?

Je pense que les bons devs utilisent les bons outils selon leurs besoins, ORM ou SQL.
Si des développeurs justifient leurs choix en disant qu'ils ne connaissent qu'un outil, ce ne sont pas des bons devs, point. Pour les préférences, visiblement, chacun a son expérience et son opinion.

[blbird]

Je pense que les bons devs utilisent les bons outils selon leurs besoins, ORM ou SQL.
Si des développeurs justifient leurs choix en disant qu'ils ne connaissent qu'un outil, ce ne sont pas des bons devs, point. Pour les préférences, visiblement, chacun a son expérience et son opinion.

Je rajouterais qu'actuellement la tendance est plutôt à la simplification et à la diminution du nombre de niveau d'abstraction, contrairement à il y a quelques années où il fallait absolument faire du MVC, voir plus (j'ai connus des apps en 5 et 6 couches, délire d'archi...).

L'ORM n'est qu'une couche supplémentaire, il faut voir ce qu'elle apporte par rapport à ce qu'elle coûte, au niveau de sa mise en place, du développement, de la maintenance, de la rapidité de l'application et de l'impact potentiel sur les utilisateurs.

Pour ma part, le choix est vite fait. A niveau de développeurs et d'archi équivalents, un ORM n'apporte que très peu (voir rien) dans chacun de ces domaines par rapport à son coût.


Et sinon, un dev qui comprend bien les technos qu'il utilise jusqu'au bout sera toujours meilleur que celui qui s'en fiche et préfère utiliser une couche d'abstraction sans chercher plus loin.

[escartefigue]

Je pense que les bons devs utilisent les bons outils selon leurs besoins, ORM ou SQL.

Sous réserve qu'on leur en laisse le choix, ce n'est pas toujours le cas, les normes internes aux entreprises sont contraignantes et des fois aberrantes (poids de l'histoire et résistance au changement...)

[deltree]

Alain Berthoz n'est quand même plus très néo

Ah, je connaissais pas, enfin ça reste un néologisme par définition, tant qu'il est pas entré dans le dictionnaire de l'académie française, ou alors un solécisme, enfin on ne va pas entrer dans un débat sur la linguistique, c'est pas le sujet.