+ Répondre à la discussion Actualité déjà publiée
Page 6 sur 11 PremièrePremière ... 2345678910 ... DernièreDernière
  1. #101
    Invité
    Invité(e)

    Par défaut

    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 ?

  2. #102
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 851
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 851
    Points : 7 180
    Points
    7 180

    Par défaut

    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.

  3. #103
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 673
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 673
    Points : 8 745
    Points
    8 745
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par Bourgui Voir le message
    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...

    Citation Envoyé par Bourgui Voir le message
    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)
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  4. #104
    Membre régulier

    Profil pro
    Inscrit en
    mars 2008
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2008
    Messages : 38
    Points : 107
    Points
    107

    Par défaut

    Citation Envoyé par Maximilian Voir le message
    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?

  5. #105
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 500
    Points
    3 500
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par loicmidy Voir le message
    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,......

  6. #106
    Membre expérimenté
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 252
    Points : 1 413
    Points
    1 413

    Par défaut

    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.

  7. #107
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 500
    Points
    3 500
    Billets dans le blog
    2

    Par défaut

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

  8. #108
    Membre régulier
    Profil pro
    Inscrit en
    mars 2005
    Messages
    62
    Détails du profil
    Informations personnelles :
    Localisation : France, Finistère (Bretagne)

    Informations forums :
    Inscription : mars 2005
    Messages : 62
    Points : 78
    Points
    78

    Par défaut

    @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

  9. #109
    Membre chevronné
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 272
    Points : 2 014
    Points
    2 014

    Par défaut

    Citation Envoyé par arfany Voir le message
    @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.

  10. #110
    Membre chevronné
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 272
    Points : 2 014
    Points
    2 014

    Par défaut

    Citation Envoyé par arfany Voir le message
    @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...

  11. #111
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 500
    Points
    3 500
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par arfany Voir le message
    @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).

  12. #112
    Membre expérimenté
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 252
    Points : 1 413
    Points
    1 413

    Par défaut

    À 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 !

  13. #113
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 851
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 851
    Points : 7 180
    Points
    7 180

    Par défaut

    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.

  14. #114
    Membre chevronné
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 272
    Points : 2 014
    Points
    2 014

    Par défaut

    Citation Envoyé par _skip Voir le message
    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...

  15. #115
    Membre expérimenté Avatar de davcha
    Profil pro
    Inscrit en
    avril 2004
    Messages
    1 256
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : avril 2004
    Messages : 1 256
    Points : 1 436
    Points
    1 436

    Par défaut

    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.

  16. #116
    Membre chevronné
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 272
    Points : 2 014
    Points
    2 014

    Par défaut

    Citation Envoyé par davcha Voir le message
    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.

  17. #117
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 500
    Points
    3 500
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par B.AF Voir le message
    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

  18. #118
    Membre chevronné
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 272
    Points : 2 014
    Points
    2 014

    Par défaut

    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.

  19. #119
    Membre régulier

    Profil pro
    Inscrit en
    mars 2008
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2008
    Messages : 38
    Points : 107
    Points
    107

    Par défaut

    Citation Envoyé par dingoth Voir le message
    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?

  20. #120
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 851
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 851
    Points : 7 180
    Points
    7 180

    Par défaut

    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.

Discussions similaires

  1. Les IDE sont-ils dangereux pour les développeurs ?
    Par Cedric Chevalier dans le forum Actualités
    Réponses: 85
    Dernier message: 13/05/2014, 11h41
  2. [Lazarus] Les composants de la JVCL sont-ils utilisables ?
    Par martinus45 dans le forum Lazarus
    Réponses: 3
    Dernier message: 11/09/2009, 19h37
  3. Réponses: 30
    Dernier message: 06/09/2009, 08h17
  4. Réponses: 5
    Dernier message: 14/08/2009, 08h55
  5. pourquoi X et GCC sont ils dangereux?
    Par ranell dans le forum Sécurité
    Réponses: 13
    Dernier message: 23/11/2008, 23h13

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo