Publicité
+ Répondre à la discussion
Page 6 sur 6 PremièrePremière ... 23456
Affichage des résultats 101 à 112 sur 112
  1. #101
    Membre Expert

    Homme Profil pro Michel
    Chef de projet MOA
    Inscrit en
    janvier 2006
    Messages
    595
    Détails du profil
    Informations personnelles :
    Nom : Homme Michel
    Âge : 47
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : janvier 2006
    Messages : 595
    Points : 1 163
    Points
    1 163

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    Perso, en tant que spécialiste COBOL-MVS, je suis encore plus bourrin. La base de données, elle sert aux transactions. Pour le batch, je la décharge dans un fichier plat, je la traite, et je la retraite. La nuit, évidemment. Sur nos machines, c'est juste 100 à 200 fois plus performant que de faire des UPDATE partout.
    @el_slapper : MERCI pour ce moment de nostalgie que tu viens de nous offrir, ca faisait un moemnt que j'avais plus vu du PIC X(80) ou du PERFORM ... UNTIL FIN-FCHIER... J'en ai presque une larme d'émotion au coin de l'oeil...
    J'aime aussi cette approche "vantage" des batches avec extraction traitement et ré-injection. C'est vrai que bourriner comme des malades une BDD pendant toute une nuit alors qu'on peut tranquillement bosser sur du séquentiel indexé est une mode qui malheureusement à mon avis est passé bien trop vite.

    Avant, pour aller dans le champ du père Matthieu, avant on avait un tracteur et on le faisait en 5 minutes. Maintenant on le fait en Ferrari climatisée en 4 minutes, après avoir investi des millions pour faire une magnifique route 3 voies qui ne sert pas... Et à l'arrivé, ben mince alors, on n'a pas de remorque... Qu'à cela ne tienne, y a qu'à envoyer un camion. Avec une remorque pour ramener la Ferrari... Ah ouais mais du coup il me faut un autre chauffeur... Pfff l'agriculture comment ça coute cher...

    @ tous les autres : MERCI aussi pour ce moment de nostalgie qui me rappelle "L'école des Fans", là où tout le monde avait 10...
    Ca fait pas loin de 4 pages que tout le monde est (presque) d'accord pour dire qu'il n'y a pas de bonne ou de mauvaise méthode ni paradigme (j'adore ce mot il fait savant) juste une solution plus ou moins adaptée à une problématique.

    Encore 10 pages et on arrête ?
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  2. #102
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro Logan
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 137
    Détails du profil
    Informations personnelles :
    Nom : Homme Logan
    Âge : 29
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 137
    Points : 4 787
    Points
    4 787

    Par défaut

    Citation Envoyé par yann2 Voir le message
    modèle de domaine anémique = Classe ayant simplement des propriétés. En gros un graphe objet sans comportement. Qu'est ce que ça implique ?

    - Pas d'encapsulation du comportement (il n'y en a pas)
    - Pas d'encapsulation des données nécessaires à l'implémentation du comportement (l'intelligence est "ailleurs" et donc tout doit être exposé).
    - Presque pas d'héritage (on hérite juste des propriétés mais, pas des comportements).
    - Pas de polymorphisme (je mets de côté la surcharge qui peut être pratique quand celle ci est résolue dynamiquement mais, ça ne va pas changer la donne de notre problème si c'est résolu statiquement : à la compilation).

    Martin Fowler précise qu'en utilisant ce genre de design on obtient :
    - les inconvénients du paradigme OO (en donnant l'exemple du mapping Objet-Relationnel)
    - sans les avantages du paradigme OO (j'en ai cité plus haut).
    En fait je vois plusieurs problèmes, comme je l'avais déjà évoqué, à mon sens il n'y a pas d'avantage au paradigme OO par rapport au "pur procédurale".

    Ensuite les projets, de mon expérience, sont toujours très spécifique en termes de besoin et de métier. Il y a donc peu de place à la "généricité" (ou "abstraction" pour employer le bon terme). Ce qui provoque deux choses :
    - Il y a peu ou pas d'héritage, et donc autant d'intérêt pour le polymorphisme
    - Les comportements sont rarement "distribués", contrairement aux données. Ce qui implique une organisation plus fonctionnelle des comportements.

    D'où les "service layer" et les modèles anémiques.


    En ce qui concerne les interfaces (GUI, REST) en revanche, on trouve des objets (JSF Bean, Struts Form, Controller) qui correspondent plus au modèle full-OO.


    Enfin, je pense que personne n'a envie d'engager toute l'équipe dans un débat conceptuelle sur quel objet à la responsabilité de la gestion des stocks des produits d'une commande, sans parler tout ce qui peut graviter autour de la gestion d'une commande : notification, fidélisation, réduction, priorité, etc.
    On tombe rapidement sur un délestage des responsabilités à coup de patterns : Commande, Stratégie, State machine, etc.
    Java : Forum - FAQ - Java SE 8 API - Java EE 7 API
    Articles sur Ceylon : Présentation et installation - Concepts de base - Typage

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  3. #103
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 722
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    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 722
    Points : 6 894
    Points
    6 894

    Par défaut

    Citation Envoyé par arkhamon Voir le message
    @ tous les autres : MERCI aussi pour ce moment de nostalgie qui me rappelle "L'école des Fans", là où tout le monde avait 10...
    Ca fait pas loin de 4 pages que tout le monde est (presque) d'accord pour dire qu'il n'y a pas de bonne ou de mauvaise méthode ni paradigme (j'adore ce mot il fait savant) juste une solution plus ou moins adaptée à une problématique.

    Encore 10 pages et on arrête ?
    Je sais pas pour les autres mais je touve cette discussion sur la conception assez intéressante pour ma part, avec des interventions de bonne facture. Je trouve que ça change des topics à la "C'est quoi un bon développeur? bennnn euh tuwa cé un bon développeur, quoi..." et des trolls de 1500 pages à la "mon langage il est mieux que le tien".

  4. #104
    Membre Expert Avatar de yann2
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2004
    Messages
    806
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2004
    Messages : 806
    Points : 1 277
    Points
    1 277

    Par défaut

    Bonjour

    Pour te répondre skip_, je suis également d'accord avec toi il y a beaucoup de choses à mettre dans la balance. Parce qu'on a plus souvent à faire au spectre complet de lumière et non pas seulement au blanc et au noir. J'aime beaucoup l'exemple de la BDD parce que ça montre qu'on échoue complètement à abstraire la source de données. Le fait que nos données soient dans une Base de données relationnelles va forcément influencer le développement de l'application. Je me demande souvent pourquoi on essaie autant de cacher qu'on utilise une BDD alors, qu'au contraire, elle a un énorme impacte !

    En ce qui concerne le lazy loading, aujourd'hui je me demande vraiment si le côté pratique du chargement automatique d'une référence par un framework de mapping O/R comme hibernate vaut la chandelle. En effet, c'est une grosse source de problème de performance. Le lazy loading en lui même, c'est bien. Mais, le fait que le chargement soit "silencieux" (point de vue du développeur) et peut potentiellement provoquer une requête en BDD peut vite plomber les performances. Et, dans, certains cas on ne s'en rendra compte qu'avec une base de données relativement importante. C'est à dire, soit à la mise en production ou encore pire, après plusieurs années d'utilisation. C'est pratique mais, c'est une source d'erreur. Bref, peut être qu'il faudrait que ce soit un peu moins transparent.

    Après, ce genre d'erreur peut également être fait dans les services. Le problème est juste déporté. On a l'illusion que c'est mieux contrôlé mais tu n'es pas à l'abri qu'un collègue ajoute une boucle pour appeler la méthode updateCommande(), par exemple, avec un getXxx malheureux ce qui va lancer 100 000 requêtes alors qu'on aurait pu en avoir une seule

    Je me demande vraiment si, justement, le rôle du service n'est pas, en premier lieu, de charger le graphe complet (pas plus, pas moins) nécessaire à la bonne réalisation du service. Et, si un objet manque... bah on explose (c'est radical mais, au moins, on s'en rend compte tout de suite). Un peu comme un main qui va instancier les objets et démarrer l'application. Bon, là... je ne donne pas de solutions :p peut être qu'une couche persistance un peu plus intelligente. Ou alors du lazy loading moins, transparent. Comme ça, le développeur sait que cet appel peut potentiellement provoquer une discussion avec la BDD. Je pense que, comme d'habitude, il n'y a pas de réponse universelle.

    Yann

  5. #105
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 722
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    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 722
    Points : 6 894
    Points
    6 894

    Par défaut

    Citation Envoyé par yann2 Voir le message
    J'aime beaucoup l'exemple de la BDD parce que ça montre qu'on échoue complètement à abstraire la source de données. Le fait que nos données soient dans une Base de données relationnelles va forcément influencer le développement de l'application. Je me demande souvent pourquoi on essaie autant de cacher qu'on utilise une BDD alors, qu'au contraire, elle a un énorme impacte !
    +1000
    C'est une dérive qui veut qu'on doive tout cacher, ou plutôt tout abstraire...
    Je pense que c'est vraiment une erreur de considérer la BDD comme citoyen de 2e classe, en tout cas à l'heure actuelle. Tout comme les théories qui prônent une séparation claire et nette de la couche BDD et de la couche Service. Si je suis d'accord entre la séparation de l'UI et du service, j'ai beaucoup plus de mal avec la séparation service et persistance.
    Pour moi, dire qu'une DAO doit être réalisée de façon à ce qu'on puisse changer de source de données sans modification des couches supérieures, c'est de la science fiction. On bosse pas de la même manière si on a un fichier XML, une BDD ou un webservice comme source de donnée.

    Ce n'est qu'en tenant compte des spécificités du système de stockage qu'on arrive à organiser une application de façon à ce qu'elle soit efficace et performante.

    En ce qui concerne le lazy loading, aujourd'hui je me demande vraiment si le côté pratique du chargement automatique d'une référence par un framework de mapping O/R comme hibernate vaut la chandelle. En effet, c'est une grosse source de problème de performance. Le lazy loading en lui même, c'est bien. Mais, le fait que le chargement soit "silencieux" (point de vue du développeur) et peut potentiellement provoquer une requête en BDD peut vite plomber les performances.
    Je te rejoins à 100%, si tu balances entre tes couches des objets mappés qui ont besoin de charger eux-mêmes des relations, cela signifie que tu n'es pas certain de la façon dont ils seront utilisés et c'est aussi là que se situe le paradoxe. D'un côté on veut un max d'abstraction, des objets auto-suffisants et de l'autre on aurait besoin de contrôler finement ce genre de chose.

    Pour ma part, j'ai délaissé les ORM à la hibernate pour me recentrer sur les solutions plus SQL, comme mybatis ou Jooq (que je pense à présenter sur DVP un de ces jours). Je reconnais leurs avantages mais je pense que les inconvénients sont trop nombreux pour mon usage. Et chaque fois que j'ai vu des tentatives de mélanger objets mappés et code métier, ça aboutissait à des pertes de cheveux.

    Après, ce genre d'erreur peut également être fait dans les services. Le problème est juste déporté. On a l'illusion que c'est mieux contrôlé mais tu n'es pas à l'abri qu'un collègue ajoute une boucle pour appeler la méthode updateCommande(), par exemple, avec un getXxx malheureux ce qui va lancer 100 000 requêtes alors qu'on aurait pu en avoir une seule
    On est toujours obligé de savoir ce qu'on fait, comme tu l'as bien indiqué dans ton premier post. Mais les choses sont plus prévisibles si on évite la surabstraction.

    Je me demande vraiment si, justement, le rôle du service n'est pas, en premier lieu, de charger le graphe complet (pas plus, pas moins) nécessaire à la bonne réalisation du service. Et, si un objet manque... bah on explose (c'est radical mais, au moins, on s'en rend compte tout de suite). Un peu comme un main qui va instancier les objets et démarrer l'application. Bon, là... je ne donne pas de solutions :p peut être qu'une couche persistance un peu plus intelligente. Ou alors du lazy loading moins, transparent. Comme ça, le développeur sait que cet appel peut potentiellement provoquer une discussion avec la BDD. Je pense que, comme d'habitude, il n'y a pas de réponse universelle.
    Non en effet, ma réponse a été de dire que la partie service et la partie BDD devait être plus intimes et qu'un graphe chargé devait être traité le plus localement possible et en aucun cas être balancé à gauche à droite jusqu'à ce qu'on se mange une exception parce qu'on a voulu utiliser une éventuelle relation non chargée.

  6. #106
    Membre Expert Avatar de chaplin
    Inscrit en
    août 2006
    Messages
    1 215
    Détails du profil
    Informations forums :
    Inscription : août 2006
    Messages : 1 215
    Points : 1 571
    Points
    1 571

    Par défaut

    Citation Envoyé par Nemek Voir le message
    Enfin, je pense que personne n'a envie d'engager toute l'équipe dans un débat conceptuelle sur quel objet à la responsabilité de la gestion des stocks des produits d'une commande, sans parler tout ce qui peut graviter autour de la gestion d'une commande : notification, fidélisation, réduction, priorité, etc.
    On tombe rapidement sur un délestage des responsabilités à coup de patterns : Commande, Stratégie, State machine, etc.
    Tant que le cahier des charges n'est pas clair, le modèle conceptuel est "flottant", d'où l'intérêt de travailler en mode itératif, une façon de travailler proposée dans la méthode agile. Concrètement, au début on réalise un prototype qu'on améliore et qu'on complète au fil des itérations.

  7. #107
    Membre éclairé
    Homme Profil pro
    Directeur de projet
    Inscrit en
    octobre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur de projet

    Informations forums :
    Inscription : octobre 2012
    Messages : 117
    Points : 321
    Points
    321

    Par défaut

    Citation Envoyé par chaplin Voir le message
    Tant que le cahier des charges n'est pas clair, le modèle conceptuel est "flottant"...
    Très à la mode aujourd'hui avec les approches Lean, http://en.wikipedia.org/wiki/Lean_software_development, au delà de l'effet de mode, j'aime bien le principe "décider aussi tard que possible" et "plus le système est complexe, plus anticipez qu'il puisse changer", simples principes de bon sens qui fait que l'on fait des "petits bouts" que l'on assemble qu'ensuite et que l'on peut justement plus facilement réassembler.

  8. #108
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 189
    Détails du profil
    Informations personnelles :
    Âge : 57

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 189
    Points : 14 368
    Points
    14 368

    Par défaut



    Tout à fait, et ça, oui, c'est la base même de "l'Agilité", que je mets entre guillemets car c'est le fond du Manifeste et de ce que voullaient dire ses auteurs (et n'importe qui ayant pratiqué dans des gros projets suffisamment longtemps)

    Et donc () comme tu peux le voir d'après tes propres dires, peu de rapport avec le design précis, ni même le fait que ce soit BD ou pas..

    C'est une approche générale de la conception des logiciels...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  9. #109
    Membre éclairé
    Homme Profil pro
    Directeur de projet
    Inscrit en
    octobre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur de projet

    Informations forums :
    Inscription : octobre 2012
    Messages : 117
    Points : 321
    Points
    321

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    ...Et donc () comme tu peux le voir d'après tes propres dires, peu de rapport avec le design précis, ni même le fait que ce soit BD ou pas..

    C'est une approche générale de la conception des logiciels...
    Effectivement, je réponds dans ce thread à la première partie de la question initiale de _skip, modèle "full OO" et l'article de Martin Fowler, et non à la seconde sur son lien avec les sources de données mais je ne pense pas être le seul a avoir dérivé ...

  10. #110
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro Logan
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 137
    Détails du profil
    Informations personnelles :
    Nom : Homme Logan
    Âge : 29
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 137
    Points : 4 787
    Points
    4 787

    Par défaut

    Citation Envoyé par chaplin Voir le message
    Tant que le cahier des charges n'est pas clair, le modèle conceptuel est "flottant", d'où l'intérêt de travailler en mode itératif, une façon de travailler proposée dans la méthode agile. Concrètement, au début on réalise un prototype qu'on améliore et qu'on complète au fil des itérations.
    Peu importe le nombre d'itération, on parle du modèle cible. Le résultat à l'arrivée sera bien ce que je décris.

    Ceci dit le modèle itératif n'est pas la panacée, on se traîne aussi des petits boulets dont on a du mal à se défaire surtout pour les applications déjà en production qu'il faut mettre à jour.
    Java : Forum - FAQ - Java SE 8 API - Java EE 7 API
    Articles sur Ceylon : Présentation et installation - Concepts de base - Typage

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  11. #111
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 722
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    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 722
    Points : 6 894
    Points
    6 894

    Par défaut

    Moi j'adore celui-là dans ton lien rimram31...

    Eliminate waste
    Everything not adding value to the customer is considered to be waste (muda). This includes: unnecessary code and functionality
    Les gens oublient parfois un peu vite que le plus important c'est de répondre dans les temps à un problème, typiquement un besoin de client et si possible de façon élégante.
    Respecter les bonnes pratiques à la lettre, l'indépendance de base de données, les belles architectures à 17 couches pleines d'interface et j'en passe... ça n'a du sens au final que si ça nous fait gagner concrètement quelque chose : style réduction des temps de dév ou amélioration de l'expérience utilisateur.

    Il y a un autre concept typiquement agile qui ca dans le même sens : YAGNI (you ain't gonna need it!). Ce qui en gros encourage le développeur à ne surtout pas se perdre à produire des choses qui ne sont pas vraiment demandées, pas immédiatement nécessaires qui pourraient nuire au délai de livraison au nom d'un hypothétique gain de temps ou de flexibilité dans le futur.

    Faut s'habituer au début, avec le temps et l'argent illimité on ferait tous des oeuvres d'art, mais on n'a pas souvent cette liberté.

  12. #112
    Membre Expert Avatar de chaplin
    Inscrit en
    août 2006
    Messages
    1 215
    Détails du profil
    Informations forums :
    Inscription : août 2006
    Messages : 1 215
    Points : 1 571
    Points
    1 571

    Par défaut

    Citation Envoyé par rimram31 Voir le message
    Très à la mode aujourd'hui avec les approches Lean, http://en.wikipedia.org/wiki/Lean_software_development, au delà de l'effet de mode, j'aime bien le principe "décider aussi tard que possible" et "plus le système est complexe, plus anticipez qu'il puisse changer", simples principes de bon sens qui fait que l'on fait des "petits bouts" que l'on assemble qu'ensuite et que l'on peut justement plus facilement réassembler.
    J'ai eu l'occasion de poussé à l'extrême le concept, 15 jours avant, j'ai dit qu'il fallait tout remettre à plat, mais je ne regrette pas du tout cette décision, car la solution collait au problème et surtout, si le projet avait été conçu initialement sous cette angle, la compréhension aurait été d'autant plus facile.

    Mais bon, quand on part dans la mauvaise direction en prenant l'existant comme "vérité", il faut du temps pour revenir sur la bonne direction. J'ai fait également le constat qu'un framework peut induire en erreur.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •