Discussion :

[B.AF]

Ca respire la créativité et l'innovation encore tout ça...

La où le débat est érroné c'est quand l'orateur s'en prend en à des technos qu'il ne comprend pas, ne connait pas, en s'appuyant sur des micros exemples.

C'est juste mercatique : un expert sql n'a aucun intérêt à proner l'ORM.

Ce qui est d'autant plus idiot c'est que ça reste sur des visions du développement d'il y a 15 ans, quand on faisait les tests après, que le SGBD était par forcémment mature....

Il y a un mélange des genres et un poujadisme assez écoeurant et d'ailleurs pas du tout crédible.

Ce que je triouve particuliérement détestable, c'est cette façon de jeter le bébé avec l'eau du bain, en disant que finalement, il y a des incompêtents qui font prendre des risques à leur boite en utilisant des technos. Puisqu'au final, avec ce pamphlet, c'est ce qu'un néophyte va comprendre : qu'un gars qui lui dit ORM est un fou furieux. C'est partir du principe que la plupart des developpeurs d'appli de gestion distribuée / client léger sont des gros nazes qui ne comprennent pas ce qu'ils utilisent.

Bref, c'est mal écrit, laborieux, dépassé, insultant et totalement faux. Sans compter qu'il y a un sérieux problème d'égo. "Moi", "Je"...tout est dans le négatif "navrant","il y a d'ailleurs souvent confusion"...

C'est digeste comme le guide du basic amstrad CPC.

[davcha]

Dans quel cas un ORM est vraiment intéressant ?


Même avec un ORM, la plupart du temps, on choisit de faire une couche d'accès aux données avec des méthodes du genre GetMachinByID ou GetTrucsWhere(MachinMulticritere)...

On est assez content de pouvoir faire joujou avec des criteria ou Linq.
Principalement, parce que c'est "Typesafe".
L'autre raison est que cela nous permet d'être indépendant de la base de données. Dans le genre "on pourrait pas être indépendant de la base avec du SQL hardcodé"... Euuh...

Bon, déjà, les criteria et Linq, c'est pas si typesafe que ça : le fichier de configuration n'est pas typesafe. Il suffit d'une faute de frappe pour provoquer des exceptions à l'exécution.
C'est pas pire que de devoir aller trafiquer le code SQL hardcodé, qui n'est pas typesafe non plus. Par contre, on peut rendre l'interface de l'objet d'accès aux données typesafe, lui. Et là, on obtient globalement la même chose qu'avec un ORM.

Indépendant de la base de donnée... Pas plus qu'avec du SQL hardcodé, en fait. Là, le truc, c'est qu'il faut s'en tenir à la norme SQL. On peut aussi s'amuser à mettre la DAL dans une dll à part, ce qui permet de dériver cette dll en autant de SGBD spécialisés que nécessaire. Ca demande pas énormément de temps non plus si on a bien foutu son boulot.


L'utilisation d'ORM fait gagner du temps... Là, quelque part, je suis d'accord et en même temps, j'ai des doutes.
Quand on voit un truc comme (N)Hibernate qui est tellement complexe/complet qu'il devient nécessaire de passer par une phase d'apprentissage similaire à l'apprentissage du SQL lui-même (voir plus complexe que le SQL, parce que ceux qui ont pondu (n)hibernate auront trouvé des solutions aux divers problèmes de persistance qui ne plairont pas à tout le monde)...
Si par contre, on maîtrise déjà un ORM, ok. Pas de phase d'apprentissage de ce côté là. En revanche, quelque part l'ORM ajoute une couche supplémentaire de "galères et d'emmerdes" : "comment je fais pour remettre mon objet détaché du contexte dans le contexte alors qu'il est parti dans un autre contexte et qu'il a été supprimé de la base dernièrement ?..."
J'admet que je caricature un peu, mais on arrête pas de voir ce genre de questions sur les forums.


Personnellement, j'ai la sensation que les ORM sont devenus comme les bases de données : des usines à gaz.
A tort ou à raison, j'en sais rien, ça.
Mais à l'origine, une base de données, c'est un outil de stockage, pas un truc qui fait des statistiques.
Et de la même façon, un ORM, c'est un outil d'accès aux données "bêbête" (lisez CRUD), pas un bidule qui sert aussi de domaine.

D'autant plus qu'on a souvent intérêt à visualiser un objet suivant différentes vues (bah oui, si on s'en fout du n° de sécu d'untel quand on regarde ses temps passés, pourquoi serait-on forcé de charger son n° de sécu ??).



Ensuite, comme l'a dit souviron, parfois, toutes les données ne sont pas sur la même base de données, le même SGBDR ou même le même serveur...

J'ajouterais que dans d'autres cas, on a affaire à des applications extensibles, et dans ces cas là, utiliser un ORM est quelque peu "foireux".
Soit on se retrouve avec un domaine différent pour chaque extension de l'appli (et donc autant de connexions.... eurk...).
Soit on se retrouve avec un domaine énorme commun à toutes les extensions, et ça brise totalement le concept d'extension, du coup, vu que tout se retrouve dépendant du même modèle, qu'il faut patcher ce modèle dès qu'une extension change et donc refaire les tests sur toutes les autres extensions... beurk².



Ce qui est marrant, c'est que j'ai l'impression que les ORM sont vraiment très intéressants dans des cas simples. Un peu comme leurs présentations marketing sur leur sites : "Avec notre ORM, oubliez la base de données ! Appuyez sur 3 bouton et hop, c'est fini !".
On se dit que c'est vraiment super cool, et par la suite, quand l'ORM se retrouve confronté à la complexité d'un cas réel, ben tout de suite, on s'arrache davantage les cheveux...

[_skip]

D'autant plus qu'on a souvent intérêt à visualiser un objet suivant différentes vues (bah oui, si on s'en fout du n° de sécu d'untel quand on regarde ses temps passés, pourquoi serait-on forcé de charger son n° de sécu ??).

Bien vu mais si cette table à 20 colonnes, seras tu d'accord d'écrire une requête SQL pour toutes les combinaisons différentes dont ton application peut avoir besoin?

ORM, JDBC pur ou pas, j'en doute fort. Si tu utilises JDBC et que tu veux une séparation minimum des couches, tu vas sans doute créer une DAL avec des méthodes de haut niveau qui te convertirons des resultsets en jolies listes d'objets.
La encore si tu acceptes que certaines propriétés de ces objets soient remplies *ou pas* suivant la méthode utilisée par le chargement ben tu es très courageux!

J'ajouterais que dans d'autres cas, on a affaire à des applications extensibles, et dans ces cas là, utiliser un ORM est quelque peu "foireux".
Soit on se retrouve avec un domaine différent pour chaque extension de l'appli (et donc autant de connexions.... eurk...).

Là j'aurai besoin d'un exemple concret parce que ça me semble un peu général comme affirmation.

[B.AF]

Je crois sans me tromper que Davcha fait une différence entre les applications qui ont un design métier naïf et les applications qui ont des "orgies" de paramétrage et où la donnée stockée est souvent inutile en l'état.

La façon de modéliser les données influe beaucoup, et pour le coup je suis d'accord avec lui : un orm est pas top

Là ou Davcha marque un point, c'est que il y a autant de gens aujourd'hui qui se servent d'un ORM ou d'un mapper sans savoir s'en servir, ainsi que pleins de gens qui crée des bdd sans tenir compte du minimum de relation ou d'utilisation des possibilités.

Mais de la même façon, je connais des personnes qui me parlent de paradigme objet mais ne comprennent pas le principe des interfaces et l'abstraction.

Après il y aussi des couches applicatives. Dans une application distribuée, il est possible que n serveurs d'applications utilisent un cluster de serveur sql, et le problème de perf va venir des graphs objets pas maitrisés, des latences,etc,etc....

Ayant déjà discutaillé du sujet avec Davcha, je trouve son avis très sage et modéré.

De la même façon que Microsoft vend que SQL server déploie des services webs en 2 clics; ç'est pas vrai, enfin si mais en démo. il faut bien séduire pour vendre.

Mais je maintiens que si dans l'équipe, il y a et les compêtences ORM et DB, il est possible de construire une couche d'accès aux données très maintenues, dans laquelle les développeurs n'auront accès qu'à ce ont ils ont besoin et de la bonne manière.

C'est un peu aussi le principe du SQL : La base peut être super bien désignée, avec l'ensemble des règles nécessaires à sa cohérence et à l'intégrité des données, ça n'empêchera jamais de produire un produit cartésien ou de faire des time outs.

C'est d'ailleurs le principe du développement d'entreprise : c'est la résultante d'un travail d'équipe homogène et réaliste, et pas le fait de star super pointues dans un sujet.

[Alain Defrance]

Cependant, être indépendant d'un SGBDR, c'est être dépendant d'un ORM .

Pas forcément, sauf erreur de ma part (ce qui est clairement possible ) si nous nous satisfaisons de JPA, alors l'implémentation reste interchangeable, (toplink, hibernate, ...)

[B.AF]

Pas forcément, sauf erreur de ma part (ce qui est clairement possible ) si nous nous satisfaisons de JPA, alors l'implémentation reste interchangeable, (toplink, hibernate, ...)

Même pas; au plus bas niveau c'est un pattern. L'indépendance de base de donnée, ça reste quand même impossible sur une appli critique.
Après sur des applis où il y a peu de données et peu d'objets, c'est envisageable.

L'erreur c'est de choisir la mauvaise techno pour faire le job.
Etre SGBD indépendant, c'est assez inutile et couteux par exemple pour un éditeur de soft : il faut quand même connaitre les deux, avoir du support des serveurs, des compêtences.

Ce n'est pas obligatoirement la panacée ou le nirvana de l'architecture logicielle.

[davcha]

Bien vu mais si cette table à 20 colonnes, seras tu d'accord d'écrire une requête SQL pour toutes les combinaisons différentes dont ton application peut avoir besoin?

Logiquement, c'est déjà ce que tu fais, même avec un ORM.
La seule différence, c'est que, dans ta DAL, au lieu d'écrire du SQL, tu écris une requête Linq, un critère ou n'importe quel équivalent, c'est à dire une phrase qui est la traduction en langage X d'une requête SQL.

L'ORM à ce niveau là a tout de même un léger avantage sur du SQL hardcodé. Il s'agit des options de mapping.... Qui me paraissent assez "inutiles" quelque part, pour peu qu'on ait accès à la base de données, mais bon.
Ce que je veux dire ici, c'est que si un jour, tu modifies ta base de données, et que tu transformes un héritage par hiérarchie en héritage par classe ou par classe concrète... Tu n'as pas besoin dans un tel cas de modifier tes "requêtes ORM" (linq ou autre). Parce que le mapping prendra en charge ces choses là, et du coup tu peux en faire abstraction.

Trop cool non ?.... Sauf que... Si t'as pu modifier ta base de données, pourquoi t'as pas fait des vues pour manipuler des objets simples justement ? Pourquoi tu t'es fait chier à machiner des jointures de bidules trucs mappés avec du XML made-in "j'y comprends rien c'est trop verbeux" ?...
( Désolé, je viens de voir 3 épisodes de dr.house )

Si tu utilises JDBC et que tu veux une séparation minimum des couches, tu vas sans doute créer une DAL avec des méthodes de haut niveau qui te convertirons des resultsets en jolies listes d'objets.
La encore si tu acceptes que certaines propriétés de ces objets soient remplies *ou pas* suivant la méthode utilisée par le chargement ben tu es très courageux!

Déjà, comme je le disais précédemment, même avec un ORM, je crée une DAL.

Ensuite, je suis peut-être idiot, sait-on jamais... Mais je n'aime pas trop l'idée d'une application disposant d'un domaine "omnipotent".
Comme je le disais, si on s'intéresse aux temps passés, j'ai pas besoin du n° de sécu. Si je m'intéresse à l'archivage des dossiers, je me moque de savoir s'ils ont des factures qui y sont rattachées.
Alors, à moins qu'une propriété soit réellement nécessaire, elle n'apparait simplement pas. C'est pas qu'elle n'est "pas remplie", c'est qu'elle n'existe pas.

En bref, je ne me retrouve pas avec un domaine énorme et omnipotent. Je me retrouve avec une multitude de "domaines" spécialisés... +/-... En fait, une multitude d'objets qui combinés les uns aux autres peuvent former un domaine spécialisé qui est censé gérer UN job donné.
Je sais pas si je suis très clair là.

Là j'aurai besoin d'un exemple concret parce que ça me semble un peu général comme affirmation.

Justement, si je manquais de clarté précédemment, cette histoire d'application extensible va ptet m'aider à éclaircir un peu ma pensée.

Imagine une sorte d'ERP qui entre autres choses permet justement de gérer les dossiers, le personnel et les factures émises, disons.
Trois extensions : dossier, personnel et facturation.
Chaque extension est indépendante des autres. A la limite on peut considérer qu'une facture est associée à un dossier, et qu'un dossier est associé à tout plein d'intervenants... Mais il ne s'agit là que de clefs étrangères, que des données brutes. L'absence de l'extension dossier n'empêche pas la facturation de fonctionner, à partir du moment où les données existent.

Soit on se retrouve avec un unique et énorme domaine omnipotent qui gère tout... Et le programme ne marche que si les 3 extensions sont présentes du coup.... Gné ?...

Soit on se retrouve avec 3 domaines... Et dans le cas d'un ORM, souvent 1 domaine = 1 contexte = 1 connexion... Donc 3 connexions... Pour 1 utilisateur ?.... Gné ??...


Soit pas d'ORM, dans ce cas, et donc 3 domaines spécialisés qui ont des vues spécifiques des différents objets.

Ainsi l'extension facturation verra un objet minimal dossier, contenant peut-être juste le guid de l'objet, le n° de dossier et les 2-3 infos nécessaires à l'affichage d'un joli tooltip sympa quand on passe la souris sur la case "n° de dossier" de la facture....

Alors que l'extension dossier verra un objet dossier beaucoup plus complet, avec les interventions, etc... et puis aussi le nombre d'acomptes/factures sur le dossier, mais pas le détail de ces acomptes et factures ? Ou alors juste les n° d'acomptes/factures, les dates et le montant...

Enfin bref.

[nicorama]

Pour ma part, je modifie ma database, j'efface mes entities, puis j'utilise create Entities from Database de Netbeans.

Je ne travaille jamais sur mes entities, je veux pas toucher aux dialectes étranges des annotations, et encore moins au XMLNightmare.

Mais j'ai mes objets Resource qui en sont très proches. Par conséquent, puisque l'orm est typesafe, Netbeans va gentiment me montrer toutes les errerus engendrées par la majeur partie des changement dans la database.

[_skip]

@Davcha

Je te rassure, la théorie sur les domaines spécialisées est très claire et tout à fait défendable à mon sens.

En vérité j'ai pensé au départ que tu parlais d'une seule classe que tu aurais, selon les besoins de ton code, populée qu'à X pourcent.
Genre j'ai besoin d'afficher Nom-Prenom-Adresse dans une grid, je charge un objet client avec ces 3 propriétés remplies puis les 17 autres laissées vides ou nulles ce qui serait alors une source d'autogoals non négligeable.

[B.AF]

@Davcha

Je te rassure, la théorie sur les domaines spécialisées est très claire et tout à fait défendable à mon sens.

En vérité j'ai pensé au départ que tu parlais d'une seule classe que tu aurais, selon les besoins de ton code, populée qu'à X pourcent.
Genre j'ai besoin d'afficher Nom-Prenom-Adresse dans une grid, je charge un objet client avec ces 3 propriétés remplies puis les 17 autres laissées vides ou nulles ce qui serait alors une source d'autogoals non négligeable.

Non mais le principe des domaines spécialisés n'aide à rien. C'est encore une théorie qui part du principe qu'on peut développer et modéliser du métier sans le comprendre.

Comme beaucoup de développement sont basés sur une conception naïve, il en résulte une décharge de Frameworks techniques qui servent de cache misère.

Un motf de conception doit répondre à une contrainte de conception et pas à une chapelle technologique Il y a peu de cas aujourd'hui, et très ciblés ou l'archi est un élément de conception fort.

[_skip]

Je m'excuse B.A.F, c'est trop vague pour moi je suis incapable de donner forme à tes propos.

Non mais le principe des domaines spécialisés n'aide à rien. C'est encore une théorie qui part du principe qu'on peut développer et modéliser du métier sans le comprendre.

Bien que ce ne soit pas forcément ce que je fais, ça me semble pas *ignorant* de décomposer la complexité d'une grosse application en *secteurs* avec leur propres entités composées d'informations précisément utiles au dit secteur et éventuellement une interface pour les propriétés communes (Primary key etc..).

Si l'interopérabilité entre les secteurs est faible, perso ça me paraît encore assez jouable, faudrait voir dans la pratique...

[davcha]

Dans certains cas (une appli extensible, par exemple), tu n'as pas le choix de toute façon.

[B.AF]

Je m'excuse B.A.F, c'est trop vague pour moi je suis incapable de donner forme à tes propos.



Bien que ce ne soit pas forcément ce que je fais, ça me semble pas *ignorant* de décomposer la complexité d'une grosse application en *secteurs* avec leur propres entités composées d'informations précisément utiles au dit secteur et éventuellement une interface pour les propriétés communes (Primary key etc..).

Si l'interopérabilité entre les secteurs est faible, perso ça me paraît encore assez jouable, faudrait voir dans la pratique...

Je te dis que c'est une conception naïve; que la solution à beaucoup de problèmes dits d'architecture aujourd'hui est dans la conception.

Nom prénom adresse, c'est faisable dans n'importe quel langage avec n'importe quel techno.

Ce qui a du sens, c'est la logique de composant et l'encapsulation.

Par exemple, combien d'utilisateurs d'ORM ont aujourd'hui utilisé les interfaces pour laisser l'orm gérer les fameux "createdby,modifiedby,date1,date2" ? Très peu.

Idem combien utilisant un ORM ont finalement compris que la table genre
"Id, description" ne servait plus à rien ?

Le découpage, c'est une espèce d'ovni conceptuel, qui garanti à des personnes qui ne maitrisent pas pour x raison la portée métier de l'application et laissent les portes ouvertes.

Ce qui est le plus important dans la conception c'est justement de comprendre les besoins fondamentaux de ce métier. On ne peut pas raisonner sur une application médicale comme sur une application de gestion des vols, ou une application de trading et encore moins une gestion des vidéos de la bibliothèque.

Là où je peux éventuellement rejoindre SQLPro, mais où je ne suis plus d'accord avec son hyperspécialisation techno, c'est qu'aujourd'hui, trop de personnes pensent qu'un bonne appli répond avant tout à une norme de développement et à une architecture technique standard.

C'est précisemment là qu'est le principal facteur d'échec. Il ne faut croire en rien pour trouvez la solution la plus appropriée. Quelqu'un qui ne croit qu'en 1 pattern, 1 méthode, 1 langage, et 1 outil n'a aucune chance de pouvoir concevoir une application sans faire d'erreur.

[souviron34]

je n'interviendrais que très légèrement, ayant déjà dit que je n'y connaissais franchement pas grand chose dans ce domaine..

Par contre :

Je te dis que c'est une conception naïve; que la solution à beaucoup de problèmes dits d'architecture aujourd'hui est dans la conception.
...
Ce qui est le plus important dans la conception c'est justement de comprendre les besoins fondamentaux de ce métier. On ne peut pas raisonner sur une application médicale comme sur une application de gestion des vols, ou une application de trading et encore moins une gestion des vidéos de la bibliothèque.
...
Là où je peux éventuellement rejoindre SQLPro, mais où je ne suis plus d'accord avec son hyperspécialisation techno, c'est qu'aujourd'hui, trop de personnes pensent qu'un bonne appli répond avant tout à une norme de développement et à une architecture technique standard.

C'est précisemment là qu'est le principal facteur d'échec. Il ne faut croire en rien pour trouvez la solution la plus appropriée. Quelqu'un qui ne croit qu'en 1 pattern, 1 méthode, 1 langage, et 1 outil n'a aucune chance de pouvoir concevoir une application sans faire d'erreur.

Vous ne serez pas étonné d'apprendre que je souscris 10 000 % à ce point de vue

[_skip]

Ce qui est le plus important dans la conception c'est justement de comprendre les besoins fondamentaux de ce métier. On ne peut pas raisonner sur une application médicale comme sur une application de gestion des vols, ou une application de trading et encore moins une gestion des vidéos de la bibliothèque.

Oui mais dans tous ces cas qu'est-ce qu'on fait habituellement? On discute avec les utilisateurs, on tâche de savoir qui a besoin de quoi et dans quelle condition, sortir les contraintes et les difficultés éventuelles.
Je sais pas comment ça se fait ailleurs mais dans les entreprises que j'ai connues c'était largement avant la question de l'ORM...

c'est qu'aujourd'hui, trop de personnes pensent qu'un bonne appli répond avant tout à une norme de développement et à une architecture technique standard.

Peut être même que dans le fond si l'application fonctionne, est maintenable et répond aux besoins dans les délais, c'est qu'on n'a pas tout fait faux.

C'est précisemment là qu'est le principal facteur d'échec. Il ne faut croire en rien pour trouvez la solution la plus appropriée. Quelqu'un qui ne croit qu'en 1 pattern, 1 méthode, 1 langage, et 1 outil n'a aucune chance de pouvoir concevoir une application sans faire d'erreur.

Eventuellement mais je suis de ceux qui aiment savoir ce qui se fait ailleurs et comment. D'où ma présence et mon intérêt pour ce genre de topic.

J'ai été bassiné pendant longtemps par des théories sur la séparation des couches, ou tout devait être en complète abstraction au moyen d'interfaces pour pouvoir supporter *un jour* une autre base de données, parfois même des fichiers XML ou des web services...

Ben dans la pratique ça a surtout donné (pour ce que j'en ai vu) que les applics devenaient des usines à gaz over-engineerées, difficiles à modifier, avec plein de code qui n'ajoutait rien en terme de fonctionnalité *juste* pour avoir de l'abstraction et supporter des changements qui n'arriveront sans doute jamais et qui même le cas échéants ne pourraient se faire sans une sacré remise à plat.

[B.AF]

Ben là, t'as tout compris.

Voilà !


Et on va en revenir à l'éternel recommencement : c'est la conception globale qui est importante, la conception technique n'est qu'un étape.

Donc, le choix d'un ORM arrive tard, et au moment où il arrive, il doit faire du sens.

Et comme tu dis, si l'application fonctionne, est testable correctement, évolutive avec un cout technique moindre, avec des coûts de maintenance réduits, tu es pas loin d'avoir bien bossé !!!!


Dans notre métier il y a théorie et pratique, les théoriciens fondent leurs théories souvent sur des exemples triviaux et répétitifs (pet shop et autres)

Dans la pratique, l'informatique est vivante et on a tendance à oublier que développer prend aussi du temps, et que toute chose étant égale par ailleurs, une application est aussi développée avec le standards du moment.

[B.AF]

Dialogue quotidien
Soit 1 a un projet, et 2,3,4 sont développeurs...

1 - "On doit faire un nouveau projet!"
2 - "Ah ouaaaaiiiiii, cette fois, on le fait en Silverlight!"
3 - "Rhâaa nâan, ça craint, c'est gualère avec l'ORM et moi je voulais essayer glassfish."
2- "Oh oui, je sais on va utiliser Ibatis, et strut2".
3 -"Bon d'accord, mais qui est pour d'essayer un client .Net en pontage IIOP/Remoting?"
4 - "Moi!"
2 - "Moi Aussi!"
4 -"Et on peut utiliser SQL 2008 Cette fois ? Nan mais il y a plein de trucs nouveaux!!!"
3 - "Bah donc il faut un ORM"
2 - "Naaaannn on fait des SP"
4 - "Moi je propose de générer le DAL!"
3 - "Oui mais si on fait un client lourd, on fait quoi avec les entités?"
2 - "Sauf avec Java"
4 - "Ouais....Et pourquoi pas en VB tant qu'on y est?????"

1 - "Alors le but du projet c'est...."
4 - "Non attend, on sait pas encore si on peut le faire"
3 - "Oui, donnes nous des use cases UML et des spécifications"
2 - "Oui, on va avancer sur l'architecture"

Et voilà pourquoi ça foire surtout et principalement.

[davcha]

Ca semble très caricatural quand même, non ?

[rakakabe]

Ca semble très caricatural quand même, non ?

Mais c'est la triste realite, du moins dans mon cas peut etre .

[B.AF]

Ca semble très caricatural quand même, non ?

Ah oui, c'est un peu d'humour dans ce monde de brute, mais c'est la fatigue tous les jours de supporter ceux qui veulent faire de la techno pour faire de la techno, du process pour faire du process, du sgbd pour faire du sgbd...

Ca bouffe une énergie...