Discussion :

[Invité]

Sauf que la on est dans le cas d'un langage .

Et de toute manière je suis effectivement d'accord avec tes propos par rapport au framework plus généralement : la productivité gagnée (principal objectif des framework) doit toujours être comparée a la perte de temps d'apprentissage et la perte de temps en documentation due au côté boite noire.
Or sur une application la persistance est un point ultra ultra important (dans le cas d'une appli web c'est quasiment tout le taf) donc les méfaits cité ci dessus doivent être doublement pris en compte.


Comment est ce que vous vous êtes mis aux ORM (ou à un ORM en particulier) ?
Obligation dans l'environnement de travail ? Projet personnel ? Choix personnel dans le travail ?

[_skip]

Pour mon cas, il s'agissait d'un choix provenant de la difficulté de maintenance et de la productivité. Bémol toutefois, je n'utilise pas réellement un ORM au sens domain model mais plutôt au sens mapper, soit en gros : j'évite de taper trop de SQL dans mon code.

Utiliser du jdbc pur dans du code java, ou de l'ADO .net ça représente beaucoup de travail et beaucoup de code rébarbatif (conversion de resultSet en objet) et non typé, du genre qui vous explose à la figure quand vous le lancez parce que vous avez mal orthographié le nom d'une colonne, oublié de tester un NULL sur votre resultSet etc...
Sur un projet qui évolue constamment tant au niveau du schéma de la BDD que des fonctionnalités, c'est une source significative de bugs de régression.

De plus, on est parfois confronté à des situations dans lesquels les requêtes doivent être formulées dynamiquement selon une liste de critère, et là le code java devient un fouillis de concaténation conditionnelles de morceaux de jointures et de morceaux de clause where qui peut vite devenir infernal, justement à ce niveau la plupart des ORM disposent d'API très sympathiques (on pense à Criteria d'hibernate ou aux predicate de LLblgen) et fortement typées pour certaines (donc avec les noms et la syntaxe vérifiée à la compilation).

Les exemples de ce genre sont nombreux... Dans llblgen par exemple, vous disposer d'une API 100% typée pour formuler tout type de requêtes, vous profitez alors de la complétion des noms dans l'IDE, de la vérification à la compilation et d'un pont tout à fait sûr entre votre POJO et la requête SQL...

Bref perso c'est ça que je recherche dans un mapper/ORM : me simplifier l'usage de SQL, j'insiste sur ce point : *pas le cacher*, m'en simplifier l'utilisation et cette étape fastidieuse qu'est le passage de la requête jusqu'à la création de l'objet java utilisable par mon application.

Tout ce qui va plus loin dans l'OR/M, le lazy loading, les updates magiques que certains proposent, je le rejette.

[OButterlin]

Sauf que la on est dans le cas d'un langage .

Et de toute manière je suis effectivement d'accord avec tes propos par rapport au framework plus généralement : la productivité gagnée (principal objectif des framework) doit toujours être comparée a la perte de temps d'apprentissage et la perte de temps en documentation due au côté boite noire.
Or sur une application la persistance est un point ultra ultra important (dans le cas d'une appli web c'est quasiment tout le taf) donc les méfaits cité ci dessus doivent être doublement pris en compte.

L'ORM ? Un langage ???
Pas du tout, c'est plus assimilable à un framework...

Pour ce qui est de la productivité, il faut surtout ne pas perdre de vue la maintenance... et la pérennité d'une solution...

Comment est ce que vous vous êtes mis aux ORM (ou à un ORM en particulier) ?
Obligation dans l'environnement de travail ? Projet personnel ? Choix personnel dans le travail ?

Choix personnel à la base... et que j'ai fait passer à ma boite...
Absolument ras le bol de perdre du temps sur des questions aussi triviales que récupérer des données d'une base et les charger dans un objet fonctionnel représentant le coeur de métier, ou de modifier à droite à gauche du code de mise à jour parce qu'on avait changé le type d'un champ en cours de route, etc...

Par contre, quand le besoin s'en fait sentir, j'utilise du sql "natif" pour contourner une "faiblesse" de l'orm (mais il faut reconnaître que c'est très rare)

[loicmidy]

Les outils d'ORM ne sont évidemment pas des silver bullets. Personne n'a jamais prétendu qu'il fallait leur déléguer aveuglément 100 % des accès aux données.
Si 95 % des requêtes sont traitées automatiquement par l'ORM, c'est déjà très bien. Pour le reste (requêtes trop lentes ou trop complexes), il est évident qu'il faut passer par du SQL "à la main" ou une optimisation au cas par cas.

Je pense que gérer l'ensemble de la logique métier dans du code procédural au sein du SGBD serait revenir sur vingt ans de fruits du paradigme objet en matière de génie logiciel. Et aussi se priver de nombreuses pratiques de développement qui fonctionnent en synergie avec l'objet et dont l'efficacité est reconnue :

- design patterns
- refactoring
- test-driven development
- domain-driven design

j'en passe et des meilleures.

il n'y a pas eu de réponse à ce post avec lequel je suis en accord.
je relance : comment on fait un test unitaire si on gère le métier dans la base de données avec par ex du PL SQL?

[ego]

il n'y a pas eu de réponse à ce post avec lequel je suis en accord.
je relance : comment on fait un test unitaire si on gère le métier dans la base de données avec par ex du PL SQL?

ah oui, bonne question ..........on fait comment les experts en base de données et en conception ?
Je sens que ça va se corser

Désolé pour l'ironie mais je n'ai pas pu m'en empêcher car vraiment je ne comprend pas que l'on puisse aujourd'hui en arriver à des conceptions de la sorte = "tout" en base. A se demander ce qu'on fait tous ces pauvres types qui ont inventé d'autres langages que le..........à oui, au fait on l'appelle comment le langage qui permet d'écrire des proc stock et autres triggers............ben ça dépend de la base de données utilisée Monsieur c'est donc pratique à enseigner, à porter, à debugger,......

[dingoth]

Si par tests unitaires, vous entendez des tests de moins d'une seconde qui doivent renvoyer vert en permanence dans votre fenêtre Eclipse/Netbeans, il n'y en a pas, par définition.

À force de n'entendre parler que des tests unitaires, on oublie qu'il y a les tests tout court, et qu'un test-tout-court peut être écrit avant l'implémentation effective.

P.S. Le cynisme n'aide en rien.

[ego]

cynisme....oui tu as raison mais des fois ça fait du bien, c'est tout simple.
Sans rancune j'espère !

[arfany]

@ego

Désolé pour l'ironie mais je n'ai pas pu m'en empêcher car vraiment je ne comprend pas que l'on puisse aujourd'hui en arriver à des conceptions de la sorte = "tout" en base. A se demander ce qu'on fait tous ces pauvres types qui ont inventé d'autres langages que le..........à oui, au fait on l'appelle comment le langage qui permet d'écrire des proc stock et autres triggers............ben ça dépend de la base de données utilisée

Avec un peu de recul, 25 ans de dev, je retombe régulièrement sur les mêmes bases de données, avec les mêmes clés primaires, clés étrangères et intégrités référentielles. Heureusement, elles représentent souvent le savoir d'une entreprise, l'historique. Elle permet par exemple de retrouver la référence de plan d'une pièce mécanique définie en 1990. Tout cela pour dire que pour le client, son SGBD, c'est la garantie de sa pérennité
Par contre, tous les 5 à 10 ans, on refond l'interface (C/S, Web 1, Web Services, Web 2 ...) mais la base de données souvent reste sous Oracle, Sybase, SQL Server, Interbase/FireBird, PostGress ... même si de temps en temps une migration de SGBD est réalisée ... avec le plus grand soin pour ne rien perdre.
Quel plaisir, lorsque l'on trouve une base de données bien faite de faire un petit coup de "reverse ingénierie" dessus et et de retrouver un MPD plus riche en enseignements qu'une documentation imbuvable de 150 pages avec moultes contradictions ! Même s'il faut se cogner quelques "proc/Stoc" qui d'ailleurs sont souvent :

• pas mal documentées en général,
• n'excèdent pas 100 lignes et facilement compréhensibles,
• exposent leurs dépendances.

Tout cela pour dire que aujourd'hui on utilise des "ORM" pour faire l'applicatif, c'est surement bien (je ne me sens pas tenté pour ma part), mais demain (donc dans 5 à 10 ans) on risque de vous demander de passer sur l '"ORMv8 qui tue et dit papa/maman", et si la base n'a fait fait que se plier aux contraintes de l"ORM" d'aujourd'hui ou n'a pas évoluer dans son schéma ... j'espère que vous ne calculerez pas ma retraite en 2020
Nous avons la chance aujourd'hui d'être en multi tiers. Pour ma part, je ne peux qu'être d'accord avec SQLPro, nous devons remonter le plus haut possible les règles métier, de toute façon, c'est la "face cachée de l'iceberg" pour l'utilisateur et cela n'a rien a faire dans la partie "interface", la partie visible est "jetable'" dès que la mode change. De plus, la performance est surement dans les SGBD aujourd'hui, et si l'analyste/programmeur ne communique pas avec le DBA, il n'est que programmeur !

Arfany

[B.AF]

@ego
Nous avons la chance aujourd'hui d'être en multi tiers. Pour ma part, je ne peux qu'être d'accord avec SQLPro, nous devons remonter le plus haut possible les règles métier, de toute façon, c'est la "face cachée de l'iceberg" pour l'utilisateur et cela n'a rien a faire dans la partie "interface", la partie visible est "jetable'" dès que la mode change. De plus, la performance est surement dans les SGBD aujourd'hui, et si l'analyste/programmeur ne communique pas avec le DBA, il n'est que programmeur !

Arfany

Justement ce que tu dis est très juste, mais tu te rends compte que ton raisonnement ne peut positionner la règle que sur le client ou le serveur : ce sont des logiques de client serveur. Aujourd'hui nous avons aussi besoin d'applications réactives, dont les données ne sont pas nécessairement localisées dans des bases, mais sur plusieurs, où sur des technos différentes.

L'utilité de l'ORM est pleine.

Et le je dis, redis, dire qu'utiliser un ORM c'est ne plus comprendre ce qu'il y a dans la DB, c'est ne rien comprendre à la logique d'ORM. Au contraire, bien utilisé, un ORM est un excellent moyen de sensibiliser des développeurs qui travaillent sur des langages de haut niveau aux contraintes des gens qui gérent la donnée et son intégrité.

Tous les métiers n'ont pas des règles figées, tous les logiciels ne sont pas fait pour résoudre la problèmatique d'un client....L'architecture doit aussi être un levier de qualité. Sur la plupart des applications sur lesquellles j'ai travaillé, le SGBD était un composant technique commun, mais pas le seul et dont la responsabilité métier était parfois nul parce qu'intrusive. g.e : le sgbd est inapproprié au temps réel, aux traitement asynchrones, aux traitements multi zones...

Tout n'est pas blanc et noir. SQL Pro et toi avait une vision expérimenté soit, cela signifie aussi que vos avis ses sont radicalisés et que cela n'est pas un argument à jeter à la poubelle tout ce qui est plus récent que vos méthodes.

[B.AF]

@ego

De plus, la performance est surement dans les SGBD aujourd'hui
Arfany

Super, on jette la programmation paralélle, le grid, le distribué, le cache distribué, les middlewares, le multithreading...

On jette les conteneurs légers, les serveurs webs....

La performance des applications sur lesquelles tu as travaillés est dans les SGBD serait forcémment plus juste.
Et certains justement ne veulent pas de cet état de fait...

[ego]

@ego

Avec un peu de recul, 25 ans de dev, je retombe régulièrement sur les mêmes bases de données, avec les mêmes clés primaires, clés étrangères et intégrités référentielles. Heureusement, elles représentent souvent le savoir d'une entreprise, l'historique. Elle permet par exemple de retrouver la référence de plan d'une pièce mécanique définie en 1990. Tout cela pour dire que pour le client, son SGBD, c'est la garantie de sa pérennité
Par contre, tous les 5 à 10 ans, on refond l'interface (C/S, Web 1, Web Services, Web 2 ...) mais la base de données souvent reste sous Oracle, Sybase, SQL Server, Interbase/FireBird, PostGress ... même si de temps en temps une migration de SGBD est réalisée ... avec le plus grand soin pour ne rien perdre.
Quel plaisir, lorsque l'on trouve une base de données bien faite de faire un petit coup de "reverse ingénierie" dessus et et de retrouver un MPD plus riche en enseignements qu'une documentation imbuvable de 150 pages avec moultes contradictions ! Même s'il faut se cogner quelques "proc/Stoc" qui d'ailleurs sont souvent :

• pas mal documentées en général,
• n'excèdent pas 100 lignes et facilement compréhensibles,
• exposent leurs dépendances.

Tout cela pour dire que aujourd'hui on utilise des "ORM" pour faire l'applicatif, c'est surement bien (je ne me sens pas tenté pour ma part), mais demain (donc dans 5 à 10 ans) on risque de vous demander de passer sur l '"ORMv8 qui tue et dit papa/maman", et si la base n'a fait fait que se plier aux contraintes de l"ORM" d'aujourd'hui ou n'a pas évoluer dans son schéma ... j'espère que vous ne calculerez pas ma retraite en 2020
Nous avons la chance aujourd'hui d'être en multi tiers. Pour ma part, je ne peux qu'être d'accord avec SQLPro, nous devons remonter le plus haut possible les règles métier, de toute façon, c'est la "face cachée de l'iceberg" pour l'utilisateur et cela n'a rien a faire dans la partie "interface", la partie visible est "jetable'" dès que la mode change. De plus, la performance est surement dans les SGBD aujourd'hui, et si l'analyste/programmeur ne communique pas avec le DBA, il n'est que programmeur !

Arfany

Personne ne discute la pérénnité des informations stockées mais cela n'a rien à voir avec le sujet de ce thread. Et le fait que l'on ne change pas certaines bases n'est pas un gage de robustesse, bonne conception,...Je connais pas mal de bases, vieilles c'est vrai, mais qui sont de vraies..........merdes en terme de conception et heureusement que l'on a les langages "au dessus" pour essayer d'en faire quelque chose. Personne ne les a changé non pas parce qu'elles ne devaient pas l'être mais parce qu'elles étaient tellement mal foutues que l'on n'ose plus les changer/faire évoluer.
J'espère que tu n'as pas mesuré toutes les conséquences de ce que tu as dis précédemment. Par exemple, pourquoi ne sommes nous pas resté à l'assembleur et aux fichiers séquentiels ? Ne me dis pas que les SGBDR sont la solution valable pour les 100 milliards d'années qui vont suivre.
Bref, les choses changent, il ne faut certes pas tout mettre à la poubelle (et il n'a jamais été dit que ORM = négation des SGBDR et de la connaissance nécessaire qu'il faut en avoir), mais il faut savoir regarder les nouveautés en essayant de voir en quoi elles peuvent être utiles (pas toutes c'est certain).

[dingoth]

À l'inverse, on a parfois des bases qui sont excellement conçues et les applications les utilisant sont de vraies « merdes » (pour me mettre à ton niveau). Il faut arrêter de penser qu'on peut remplacer une base de données, mais surtout pas les applications les utilisant, sachant que dans la pratique, c'est l'inverse qui est généralement fait (et pas pour l'unique raison que personne n'a le courage de toucher la base de données). Alors l'argument d'interopérabilité, d'interchangeabilité, hein... Quand on change un élément de l'architecture, il est toujours nécessaire de mettre les mains dans le camboui à un moment ou à un autre. Enfin, quant aux nouveautés, elles ne sont pas le seul appanage du côté applicatif, mais bon, quand on se limite à utiliser un SGBD pour stocker des tables de données et éventuellement deux vues, on ne voit pas trop ce qui peut être injecté de nouveauté !

Ce dénigrement exclusif des bases de données me donne la nausée : il est toujours plus facile de critiquer le pré du voisin que le sien !

[_skip]

De toutes façons je vois pas où cela peut mener le débat de comparer des outils dans un contexte où ils sont employés de travers, que ce soit le SGBD (bases mal conçues) ou l'applicatif (mauvaise utilisation d'un ORM).

Je serai plutôt d'avis de dire qu'un produit est à l'image de son plus mauvais maillon, quel que soit la couche concernée... C'est ce qui ne va pas depuis le début, jusque dans l'article à la base de ce thread où l'auteur part de l'idée que parce qu'on utilise un bête mapper JDBC on ne fait forcément que des choses stupides et non performantes avec.

On s'obstine à dire que l'une de ces deux choses doit remplacer l'autre alors qu'au contraire elles peuvent tout à fait se compléter.

[B.AF]

De toutes façons je vois pas où cela peut mener le débat de comparer des outils dans un contexte où ils sont employés de travers, que ce soit le SGBD (bases mal conçues) ou l'applicatif (mauvaise utilisation d'un ORM).

Je serai plutôt d'avis de dire qu'un produit est à l'image de son plus mauvais maillon, quel que soit la couche concernée... C'est ce qui ne va pas depuis le début, jusque dans l'article à la base de ce thread où l'auteur part de l'idée que parce qu'on utilise un bête mapper JDBC on ne fait forcément que des choses stupides et non performantes avec.

On s'obstine à dire que l'une de ces deux choses doit remplacer l'autre alors qu'au contraire elles peuvent tout à fait se compléter.

Ce n'est pas tout à fait ça :
On part d'une personne qui parle de technologies. Une qu'elle connait très bien, voir même est experte, une autre qu'elle ne connait ni d'Eve ni d'Adam (ni les patterns, encore moins les frameworks et les différences).

En gros, c'est un dialogue de sourd basé sur un dogme tellement énorme que forcémment, ça vire au troll.

Comme quoi, même pas besoin de toucher un outil pour faire des choses inutiles en informatique. Bah oui, le problème des experts, c'est que malheureusement sorti de leur expertise, généralement ils ont la vu très basse. Donc ils raménent tout à leur expertise.
Et c'est ainsi que COBOL existe encore.Mais ça fonctionne. Mais c'est certain qu'intellectuellement ce n'est pas jouissif. Bref, la peur bien humaine de devenir inutile est un facteur d'erreur fabuleux chez bon nombre de concepteurs / architectes, aussi fort que le besoin du jeune d'utiliser les derniers trucs à la mode.

Enfin sur ce, jarrête là sur le sujet, sauf à en faire un constructif, ou l'on puisse faire un vrai sujet d'analyse sur la conception de modéles de données.

Parce que là, Arnold et Willy font de l'ORM et Martine fait une procstock...

[davcha]

C'est pas une très bonne idée de mettre tout le code métier dans la base de données...

Suffit que les données soient éclatées sur plusieurs systèmes et ce principe de tout mettre dans la bdd est bon à jeter.

[B.AF]

C'est pas une très bonne idée de mettre tout le code métier dans la base de données...

Suffit que les données soient éclatées sur plusieurs systèmes et ce principe de tout mettre dans la bdd est bon à jeter.

Pour généraliser, c'est jamais une bonne idée d'utiliser un procédé inapproprié à un objectif.

Et c'est tout autant une mauvaise idée que de ne pas se servir des bons outils par dogmatisme ou peur, ou d'utiliser un outil sans le comprendre.

[ego]

Pour généraliser, c'est jamais une bonne idée d'utiliser un procédé inapproprié à un objectif.

Et c'est tout autant une mauvaise idée que de ne pas se servir des bons outils par dogmatisme ou peur, ou d'utiliser un outil sans le comprendre.

Ben BAF il a tout dit !! Je suis 100% d'accord

[B.AF]

Moi, n'étant pas "pur" développeur, je trouve d'ailleurs ce côté du développeur pénible : à ne jamais contextualiser une techno.

C'est comme si je faisais du HTML statique, que je voyais un site avec du Javascript moche (et il y en a) et que donc j'en concluais que Ajax, c'est nul.

En fait le point que souléve ce sujet est bien plus large :
Comment utiliser la technologie au bénéfice de la destination fonctionnelle ?
Résumée à : Qu'est ce que le génie logiciel ?

Comme le montre d'ailleurs chichement davcha, rien qu'à prôner le tout relationnel en SQL on peut faire une erreur grave de conception.

Et comme le montre l'intégralité de ce sujet, il y a ceux qui ont une approche purement technique, d'autres une approche purement académique.

Moi, je n'aime ni l'un ni l'autre, j'aime l'approche sueur, travail, qualité et surtout résultat. Se satisfaire d'un moyen c'est (excusez moi si ça choque) complêtement stupide. C'est le raisonnement de dire je passe mon épreuve de Math au bac et que plutôt que de réviser, d'acheter une calculatrice scientifique la veille : c'est débile.

[loicmidy]

Si par tests unitaires, vous entendez des tests de moins d'une seconde qui doivent renvoyer vert en permanence dans votre fenêtre Eclipse/Netbeans, il n'y en a pas, par définition.

À force de n'entendre parler que des tests unitaires, on oublie qu'il y a les tests tout court, et qu'un test-tout-court peut être écrit avant l'implémentation effective.

P.S. Le cynisme n'aide en rien.

c'est la seule réponse que j'ai eu à ma question et cette réponse est complètement à côté de la plaque ou au minimum très floue.

Un test unitaire est un test qui permet de tester de bon comportement d'une unité fine de code (souvent une méthode). Ces tests doivent être rapide à exécuter et indépendant les uns des autres.

Il y a effectivement d'autres types de tests (intégration,fonctionnels, etc) mais les tests unitaires c'est la base.

C'est quoi un test-tout-court?


Je vais aborder le problème d'une autre façon :
si je développe mettons en PL SQL comment je fais pour écrire un test automatique et rapide à exécuter d'une unité fine de code?(pour bien me faire comprendre prenons un exemple : je code un batch qui lui même se décompose en sous batchs etc et l'unité la plus fine est le code relatif à une unique règle métier)

autre question : le refactoring de code java sous éclipse avec les outils d'aide au refactoring je connais. Comment est ce que je fais la même chose en PL SQL?

[_skip]

Pourtant sa réponse est juste...

Le test unitaire finalement c'est quoi? Exécuter une opération et vérifier qu'elle produit les résultats attentdus dans diverses circonstances.
Il est clair que ce n'est pas junit qui les a inventé pour ne citer que lui, ça se faisait bien avant.

Tu peux tester unitairement une procédure stockée au moyen d'une autre procédure stockée de test, la deuxième déclenchant la première et testant sa valeur de retour avec un RAISE ERROR.
Tu te fais un gros script de test ainsi, c'est largement faisable...

Donc c'est entièrement possible à faire, et je suppose que ça s'est toujours fait peu importe le langage.

Dans les IDE modernes, tu as la prise en charge avec les lumières vertes comme disait dingoth et le support out-of-the-box d'un framework (nUnit, Junit, phpUnit) qui te simplifie la vie. Mais ce n'est que de l'intégration, même si c'est vrai que c'est très confortable et facilement utilisable.