[Débat] modèles full OO et sources de données, est-ce un mythe?

Citation:

---

Envoyé par el_slapper

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... :ccool:
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... :aie::aie::aie:

@ 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 ? :lol:

Citation:

---

Envoyé par yann2

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.

Citation:

---

Envoyé par arkhamon

@ 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 ? :lol:

---

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".

Bonjour

Pour te répondre skip_, je suis également d'accord avec toi :P 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

Citation:

---

Envoyé par yann2

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.

Citation:

---

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.

Citation:

---

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. :ccool: Mais les choses sont plus prévisibles si on évite la surabstraction.

Citation:

---

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.

Citation:

---

Envoyé par Nemek

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.

Citation:

---

Envoyé par chaplin

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.

:ccool:

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.. :P

C'est une approche générale de la conception des logiciels...

Citation:

---

Envoyé par souviron34

...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.. :P

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é ...

Citation:

---

Envoyé par chaplin

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.

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

Citation:

---

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é.

Citation:

---

Envoyé par rimram31

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:aie:, 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.