Discussion :

[Pierre Louis Chevalier]

C'est un troll pour 2 raisons :

- confusion totale entre opinions et faits, pas de source sérieuse pour ce qu'il avance
- erreurs manifestes, raisonnements lacunaires

Ce genre d'article est de très mauvaise qualité car il ne cite aucune source. Le gars sort tout directement de son cul. Malheureusement, il y a toujours une foule qui ne vérifie pas l'info, prête à répéter ce genre de choses.

En gros, n'y a-t-il aucun travail éditorial avant de poster un article ici ? N'y a-t-il aucune recherche de qualité ?

Tu as peut être pas tord mais dans ce cas tu peu jeter à la poubelle 99% de la presse gratuite web, donc tu peu jeter developpez à la poubelle vu que c'est gratuit.
Tu crois que developpez à les moyens de payer 50 journalistes qui coûtent 10 000 euros par tête avec charges ?

La personne qui à posté la news n'à pas dit que cette "opinion" était bonne ou exacte, la personne te demande ton avis justement.
Comme tu ne sembles pas avoir compris dois je en conclure sur des faits que tu ne sait pas lire ?

Si tu es si fort fait en des news, avec des sources et tout et tout, on les lira avec plaisir.

[ymajoros]

Tu as peut être pas tord mais dans ce cas tu peu jeter à la poubelle 99% de la presse gratuite web, donc tu peu jeter developpez à la poubelle vu que c'est gratuit.

Je n'irais pas jusque 99 %, et ça n'a pour moi pas vraiment de lien avec le fait que ce soit gratuit. Plutôt avec celui que ce ne soit pas relu, vérifié, validé.

La personne qui à posté la news n'à pas dit que cette "opinion" était bonne ou exacte, la personne te demande ton avis justement.

Justement, opinion != news.

Comme tu ne sembles pas avoir compris dois je en conclure sur des faits que tu ne sait pas lire ?

Si tu es si fort fait en des news, avec des sources et tout et tout, on les lira avec plaisir.

Doit-on être journaliste pour critiquer un article pourri ? Ou on ne demandait peut-être pas vraiment l'avis ?

[Jcpan]

Avant tout je tiens à rappeler que le principale avantage de L'ORM est la migration du SGDB, aujourd'hui on travaille avec mysql demain on migre vers oracle, postgresql ou même vers du NoSQL , en changeant juste le nom de ce dernier dans la config, bien sur si on a utilisé 100% du langage ORM.
Quelqu'un peut nous éclairer pourquoi la référence NULL est la première grosse erreur en POO ?

[santana2006]

Effectivement, la couche présentation a ses propres structures et objets,

Mais le principe pour moi étant d'utiliser les entités lorsque c'est nécessaire. Par exemple, dans les combobox, ou pr le binding des éléments input de formulaires, etc..

N'oublier pas que déjà les entités du modèle de domaine, sont déjà des DTOs, échangées entre l'application et l'ORM.

D'ailleurs vous remarquer dans TOUS les tutoriels et cours relatifs aux ORM où ceux couvrant la mise en oeuvre d'approches et outils, réunissant la couche modèle et la couche de présentation, les bouts de codes des controllers (spring) ou beans (jsf) et des pages xhtml font usage des classes d'entité directement. pas de classes de DTO.
Je parle là des articles et tutos soutenus, pas de autre chose.

[_skip]

Effectivement, la couche présentation a ses propres structures et objets,
Mais le principe pour moi étant d'utiliser les entités lorsque c'est nécessaire. Par exemple, dans les combobox, ou pr le binding des éléments input de formulaires, etc..
N'oublier pas que déjà les entités du modèle de domaine, sont déjà des DTOs, échangées entre l'application et l'ORM.

Si tu le peux, pourquoi pas, effectivement si ton moteur de rendu est côté serveur là où ta session DB est ouverte et que tes entités correspondent "en l'état" à ton besoin d'affichage, tu peux les utiliser. Par contre je suis plus sceptique pour ce qui est de faire du binding formulaire => entité car il y a pas toujours une correspondance pile poil entre le formulaire et les données nécessaires (ou souvent les..) entités. Après à chacun de voir mais mon expérience tend à montrer que le code est plus propre et plus souple si j'utilise des POJO avec validation JSR, et dont je gérais ensuite la persistence avec les entités. Sinon les entités deviennent elle-mêmes des sacs de getters/setters pour les besoin du binding et on peut perdre une partie des avantages.

D'ailleurs vous remarquer dans TOUS les tutoriels et cours relatifs aux ORM où ceux couvrant la mise en oeuvre d'approches et outils, réunissant la couche modèle et la couche de présentation, les bouts de codes des controllers (spring) ou beans (jsf) et des pages xhtml font usage des classes d'entité directement. pas de classes de DTO.
Je parle là des articles et tutos soutenus, pas de autre chose.

Je remarque aussi que 80% des tutos full stack sont des applications triviales, (carnet d'adresse, TODO list, blog, tickets) résolument mono-utilisateur, sans logique et avec pas ou peu de gestion d'erreur. Des applications dans lesquelles on va jusqu'à laisser l'ORM créer les tables qu'il a envie tant la correspondance entre le module et les E/S sont 1:1. Je peux t'assurer que j'ai jamais pu faire ça avec les applications sur lesquelles je bosse.

[_skip]

Avant tout je tiens à rappeler que le principale avantage de L'ORM est la migration du SGDB, aujourd'hui on travaille avec mysql demain on migre vers oracle, postgresql ou même vers du NoSQL , en changeant juste le nom de ce dernier dans la config, bien sur si on a utilisé 100% du langage ORM.
Quelqu'un peut nous éclairer pourquoi la référence NULL est la première grosse erreur en POO ?

Parce que les NPE sont à l'origine de bugs qui a coûté des milliards à beaucoup de monde, et qu'il existe d'autres approches pour gérer l'absence de valeur comme tu peux le voir dans certains langages récents qui distinguent les types nullables et non nullable ou qui ont une gestion vérifiée par le compilateur, des sucres syntaxiques "Option(al)" etc....

Pour ce qui est du changement de base de données, malheureusement aucun de mes projets DB ne vérifie cette condition car j'ai quasiment toujours recours à des fonctionnalités trop avancées (bulk insert, gestion de date, procédure stockée) etc.... Et faut aussi voir sur combien de projets on te demande réellement de switcher de SGBD et si vraiment c'est aussi "sans effort" que sur les prospectus, car il y a parfois des différences subtiles.

[OButterlin]

Je partage l'avis de _skip, les projets sur lesquels je bosse permettent rarement de se passer de la couche DTO... et je ne parle même pas du problème des ERP vieillissant qu'on a derrière et qui gère les dates sous forme de nombre entier...
Il est vrai qu'avec JSF (pour ne citer que lui) et les converters, on pourrait faire avec... mais bon, les vues sont le plus souvent des agrégats d'informations connexes dont l'origine n'est pas forcément liée, voir même issues de DB différentes...
Pour ce qui est des applications simples avec un modèle de données simple, pourquoi pas... mais ce n'est pas le cas de nos applications ou juste pour certains bouts concernant le paramétrage.

Et pour l'indépendance des base de données, c'est beaucoup moins vrai que ce qu'on prétend. En pratique, pour les types de données, en faisant correctement le mapping (c'est à dire après une expérience où on s'est bien beurré), on peut s'en sortir à peu près... Mais il y a des choses plus subtiles, l'auto-incrément, les Blob/Clob, les procédures stockées qui ne s'interfacent pas de la même façon, etc...

Ceci dit, je ne cherche pas à convaincre, que ceux qui peuvent continuent d'utiliser l'entity directement le fassent

[santana2006]

Pour la question de migration SGBD moi aussi je ne le vois pas parmi les raisons derrière l'usage d'ORM. Les projets des entreprises de moyenne et grande taille sont à un pourcentage non négligeable basée sur Oracle. du moment où on a se dernier il n y a généralement pas le besoin de migrer vers autre chose, sauf dans des cas rares.

Sinon, pour cette question de faire du DTO ou pas, personnellement pour plusieurs raisons je travaille depuis plus de deux ans sur de la génération de code, sur un projet from scratch que je suis moi même entrain de concevoir et d'implémenter. Le défi pour moi étant de pouvoir faire du 100% IHM généré, indépendamment de la complexité de l'écran.

Je peux vous dire que c'est un objectif atteint à 100%. et c'est basé sur le travail avec les entités direct (Binding, conversion ..).

Les entités à elles seules ne sont pas suffisantes pr tout faire coté IHM bien entendu, c'est pour cela que le générateur de code génére, lorsque nécessaire, des structures (classess) personnalisées, mais qui restent quand même propre à la couche présentation (un Row d'un tableau dynamique par exemple), chose qui différe bien entendu par nature et par usage du DTO quand crée pour correspondre à une entité métier, et qu'on fait transiter entre les couches de l'application.

Pour moi le DTO n'a vraiement pas sa place. L'idée que dans les tutos les exemples sont simplistes est en gros vraie, mais c'est voulu pour que les gens comprenne le tuto.

Dans mon cas j'ai travaillé avec le générateur de code que j'ai moi même réalisé sur des projets de complexité importante, à l'aise. Je n'ai même plus besoin d'ouvrir le code des pages xhtml générées.

[_skip]

Je partage l'avis de _skip, les projets sur lesquels je bosse permettent rarement de se passer de la couche DTO... et je ne parle même pas du problème des ERP vieillissant qu'on a derrière et qui gère les dates sous forme de nombre entier...
Et pour l'indépendance des base de données, c'est beaucoup moins vrai que ce qu'on prétend. En pratique, pour les types de données, en faisant correctement le mapping (c'est à dire après une expérience où on s'est bien beurré), on peut s'en sortir à peu près... Mais il y a des choses plus subtiles, l'auto-incrément, les Blob/Clob, les procédures stockées qui ne s'interfacent pas de la même façon, etc...

Comme sur plein d'autres sujets nous sommes d'accord
Ca c'est la malédiction de notre métier, tout s'apprend à la dure... Il est sûrement possible d'être multi-sgdb si on se contente d'un certain sous-ensemble, mais c'est se priver de beaucoup de choses qui peuvent faire une différence. Je n'ai jamais vu d'entreprise dont le changement de SGBD n'entraînait pas une grosse remise en question de l'existant, un projet de migration sur le long terme, l'achat de nouveaux serveurs, des MAJ majeures de l'infra etc... Personne ne vient du jour au lendemain avec la lubie "Tiens et si on jetait tous nos serveurs X pour passer sur Y", c'est beaucoup plus compliqué que ça.

Dans mon cas j'ai travaillé avec le générateur de code que j'ai moi même réalisé sur des projets de complexité importante, à l'aise. Je n'ai même plus besoin d'ouvrir le code des pages xhtml générées.

Ceux que j'ai vu faire ce genre de chose sont windev ou RoR avec son scaffold et chaque fois avec d'important compromis. C'est visible quelque part ça?

[dfiad77pro]

La majorité des SI importants que j'ai vu utilisent à fond les procs stockées, les orms ne servent que pour une faible parti de l'ensemble, mais ça reste utile

[santana2006]

Comme sur plein d'autres sujets nous sommes d'accord
Ca c'est la malédiction de notre métier, tout s'apprend à la dure... Il est sûrement possible d'être multi-sgdb si on se contente d'un certain sous-ensemble, mais c'est se priver de beaucoup de choses qui peuvent faire une différence. Je n'ai jamais vu d'entreprise dont le changement de SGBD n'entraînait pas une grosse remise en question de l'existant, un projet de migration sur le long terme, l'achat de nouveaux serveurs, des MAJ majeures de l'infra etc... Personne ne vient du jour au lendemain avec la lubie "Tiens et si on jetait tous nos serveurs X pour passer sur Y", c'est beaucoup plus compliqué que ça.



Ceux que j'ai vu faire ce genre de chose sont windev ou RoR avec son scaffold et chaque fois avec d'important compromis. C'est visible quelque part ça?

Non rien à avoir en commun avec Windev et compagnie coté possibilité.

Le principe est simple : Je suis architecte spécialisé en Java/JEE, et ayant un retour d'expérience sur pas mal de projets sur lesquels j'ai travaillé, de diverses natures et types, j'ai ma propre conception de ce qu'est une appli JEE multi-modules réussi, coté architecture, coté technologies, et coté facilité de développement. Plus le volet performance.

J'ai mis à part les frameworks classiques de génération de code, vu que c t un peu démodé et limité (style Andro MDA).

Je me suis orienté vers la technologie DSL (xText, xTend ..)

Après bcp de temps passé sur ce projet de générateur de code, basé essentiellement les standards sur JSF, CDI, EJB, JPA + Maven. J'ai obtenu :

• Un langage DSL personalisé
• Un plugin eclipse pour l'édition de mon langage
• Un générateur à base de mon langage

Les résultats que j'ai atteint sont intéressantes :

• 100% Xhtml
• 80% du code des beans JSF
• 90% de la couche DAO
• 0% SQL (Sauf pr les requêtes synthétique ou de reporting
• 100% d'API criteria avancé (grâce à elle j'ai pu atteindre le 0% SQL)
• 100% des clés des messages properties (internationalisation)
• 100% détachement entre couche présentation et ce qui vient plus bas (métier, dao).. Chose qui m'a permi de faire de la génération de couche Swing avec le même langage/syntaxe DSL.
• 80% de la couche Swing générée (Dans le cas de client lourd

Peut être les chiffres paraissent un peu exagérée, mais ils sont véridiques. C'est testé et approuvé.

Le seul truc à améliorer : la portabilité serveur, en effet actuellement les sources produits sont compatibles uniquement avec JBoss Wildfly.

Si besoin est, je travaillerais sur le support d'autre serveur.

C'est visible quelque part ça?

Malheureusement non, car je vais en faire un projet commercial.

[professeur shadoko]

Parce que les NPE sont à l'origine de bugs qui a coûté des milliards à beaucoup de monde, et qu'il existe d'autres approches pour gérer l'absence de valeur comme tu peux le voir dans certains langages récents qui distinguent les types nullables et non nullable ou qui ont une gestion vérifiée par le compilateur, des sucres syntaxiques "Option(al)" etc....
.

ça mériterait un flux de discussion distinct.
Que faire quand une donnée est "optionnelle" ? ... s'assurer que le code qui la manipule tient compte de cette absence...
par contre le fait d'avoir des objets "neutres" (comme on le voit parfois dans certaines préconisations) est une erreur encore pire .... on a quelque chose ou on ne l'a pas!

[B.AF]

Le raisonnement est tellement simpliste que ca n'appelle même pas une réponse.

La vraie question de ce sujet est : est-ce une bonne pratique de déléguer des couches applicatives a des frameworks qui lient des concepts que les développeurs ne maîtrisent pas ?

Utiliser un orm peut être un frameworks connu, base ou pas sur une spécification, libre ou payant, spécialise sur moteur ou multi drivers, faut il mapper a a la main ou recourir à la génération de code...

Mais ça se transpose sur pleins de techno y compris sql.

[ymajoros]

Le raisonnement est tellement simpliste que ca n'appelle même pas une réponse.

Je n'ai qu'un message : l'auteur ne cite aucune source = article mauvaise qualité, qu'est-ce que ça fait ici ? De ce que je lis plus haut, il n'y aurait aucun contrôle de qualité ????

Ce n'est pas simpliste, c'est juste simple :

- L'article parle-t-il de faits ou d'opinions ?
- Ces opinions sont-elles partagées ? Y a-t-il eu d'autres recherches sur le sujet ?

Les réponses sont évidentes, non ?

Dans ce cas, je vais réutiliser une expression populaire que tout le monde utilise, même si ce n'est pas de bon ton : cet article, c'est de la grosse merde. Ça rend mon message clair, même si je sais que certains feront plus attention à la forme qu'au fond.

Et oui : je critique et ne propose pas d'autre article (pour l'instant). Quand je vois ce genre d'articles de basse qualité traîner, et qu'on permet de donner son avis, je le donne. On ne peut pas être en désaccord avec le sujet, on ne peut pas relever ses erreurs manifestes ?

En résumé : cet article n'est basé que sur des vagues avis de l'auteur.

[masivelo]

La raison d'être d'un ORM est l'impedence mismatch entre l'object model et le relational model. Si l'approche objet serait accepté comme étant la meilleure pour la programmation, le fait de dire que l'ORM est une grosse erreur revient à dire que c'est le modèle relationnel même qui est une grosse erreur. Il faut dans ce cas trouver une autre façon de persister et interroger les objets avec au moins les mêmes performance que celle du modèle relationnel et on a même pas besoin de SQL-Speaking-Object !

[masivelo]

De plus ample explication serait nécessaire pour mieux comprendre la motivation de l'article.

[ddoumeche]

Personnellement je pense que c'est plutôt le sql qui est un antipattern : en avoir fait l'API de référence alors qu'il s'agit d'un langage d'interaction conçu pour les humains, oblige a des contorsions et du parsing coûteux de chaque requête.
Oui il y a les procédures stockés mais ce ne sont que des palliatifs imparfaits.

Les ORM et notament leur Api ont su s'imposer parce qu'ils définissent une API standard d'accès aux données, c'est aussi une des raisons du succès des serveurs NoSQL (même si je n'aime pas ce que recouvre cette technologie en réalité).
Si vous regarder cette petite merveille d'architecture de Mysql cluster, vous serez surpris de voir qu'un client évite le plus souvent la couche SQL en se connectant directement au moteur de données (NDB) et en utilisant l'api JPA (meme si le drivers en dessous est spécifique).

[santana2006]

Le SQL n'est pas aussi mal que ça. Il a tjrs sa place vu les millions d'applis pr entreprise ou autres, qui nécessitent une base de données.

L'ORM n'a pas pr but de remplacer le SQL, donc les comparer c'est pas vraiement ce qu'on doit faire, n'oublier pas que l'ORM a sont propre QL à lui (JPAQL, HQL..).

Disons qu'avec un ORM on obtient :

• Une séparation nette entre la couche données et l'application
• Moins de lignes de codes à taper pour la conversion Objet <---> SQL
• On délégue la gestion des connexions, l'aspect transactionnel, le vérouillage et autres trucs aux couches sous jascentes
• On sépare néttement entre le monde relationnel, et le monde objet, on se concentre sur le raisonnement/conception/modélisation/développement orienté objet, et on laisse l'ORM faire le reste

ORM et SQL ne se contredisent pas.

[OButterlin]

Personnellement je pense que c'est plutôt le sql qui est un antipattern : en avoir fait l'API de référence alors qu'il s'agit d'un langage d'interaction conçu pour les humains, oblige a des contorsions et du parsing coûteux de chaque requête.
Oui il y a les procédures stockés mais ce ne sont que des palliatifs imparfaits.

Les ORM et notament leur Api ont su s'imposer parce qu'ils définissent une API standard d'accès aux données, c'est aussi une des raisons du succès des serveurs NoSQL (même si je n'aime pas ce que recouvre cette technologie en réalité).
Si vous regarder cette petite merveille d'architecture de Mysql cluster, vous serez surpris de voir qu'un client évite le plus souvent la couche SQL en se connectant directement au moteur de données (NDB) et en utilisant l'api JPA (meme si le drivers en dessous est spécifique).

SQL antipattern, c'est comme dire Java antipattern... C'est un langage de requête normalisé, ni plus, ni moins...
Qui plus est, l'ORM s’appuie sur JDBC pour accéder à la base de données sous-jacente, la comparaison n'est vraiment pas appropriée

Et l'ORM ne définit pas du tout un standard, il suffit de voir les différences entre Hibernate natif et EclipseLink ou JPA.
JPA est un standard JEE, c'est tout.

Maintenant, dire que l'ORM est bien parce qu'on s'affranchit du langage SQL me laisse toujours dubitatif... C'est plus assimilable à de la paresse intellectuelle qu'à une réelle valeur ajouté.
Je ne vois pas non plus de lien avec "...oblige a des contorsions et du parsing coûteux de chaque requête"...
Il n'y a pas plus proche du modèle physique que JDBC, donc je suppose que tu fais références à des changements de type entre le modèle physique et l'objet représentant les données... ça, l'ORM le fait de façon paramétrable à la place du développeur (et c'est à mon avis sûrement la meilleure partie de l'ORM) mais bon, ça ne représente pas non plus une charge de travaille importante et on peut facilement générer cette phase par un outil.

L'ORM est un outil de plus mis à la disposition des développeurs, il a des avantages et des inconvénients comme tout autre framework.
C'est sa bonne ou mauvaise utilisation que fera la différence.

[santana2006]

C'est sa bonne ou mauvaise utilisation que fera la différence.

J'aime bien. ça resume tout.