Discussion :

[clecle]

Bonjour,

Je suis en train de concevoir une nouvelle application.

Pour la partie persistance mon modèle métier contient un graphe d'objet. (Un objet a une collection d'un autre objet qui elle même contient une autre collection).
J'ai un implémenté ma couche de persistance avec JPA et j'ai des façades pour l'attaquer.


Pour ma couche de présentation, j'ai quasiment le même modèle mais avec des attributs supplémentaires qui sont initialisé lors de la créations des objets, ces attributs me permette d'améliorer et de gérer l'affichage.

Maintenant j'ai donc deux couches parfaitement séparé. Mais j'aimerais bien alimenté mon modèle de présentation grâce a ma persistance et modifier ma persistance depuis la présentation.

Ma question qu'elle est la meilleure méthode pour faire la "glue" entre le tout?

Merci

[eulbobo]

Vu comme tu as architecturé ta solution, tu vas forcément avoir besoin à un niveau d'avoir une référence vers l'un des univers : ta présentation qui dépends des classe de persistance, ou tes classes de persistance qui dépendent de tes classes de présentation.

Ca ressemble beaucoup à un mode de développement que j'ai connu il y a quelques années: le système par vues. Chaque objet persisté était d'abord transformée dans un objet spécifique de présentation avant d'être envoyé dans la couche de présentation, et chaque objet de la couche de présentation était systématiquement transformée dans un objet de persistance.
J'ai vu plusieurs mode
- l'objet de type vue qui avait un constructeur auquel on passait un objet de persistance, et qui avait une fonction pour créer un nouvel objet de persistance... Très mauvaise idée parce qu'on avait du coup des erreurs de tous les côtés dans les conversions de données, que la moindre modification d'une valeur à un endroit devait être traquée de partout pour vérifier qu'on oubliait rien
- l'utilisation de copie de beans par introspection (BeanUtils.copyProperties). En théorie une bonne idée, mais le moindre changement de type et de nommage faisait que des champs n'était pas copiés. Du coup là encore beaucoup de temps perdu pour pas grand chose. Et TRES TRES coûteux en terme de CPU (surtout pour afficher une liste de 500 items avec chacun plus de 30 propriétés)

Au final, l'intérêt de la chose était quasiment nul puisque la couche de présentation avait quand même des dépendances directes à la couche de persistance, et que ça ne faisait que rajouter des classes qui n'ajoutaient rien.


Du coup, l'idée a été abandonnée dans la suite des développements.


Dans ton cas, si tu as des objets côté persistance qui sont des graphes d'objets, je te déconseille fortement le système par vue : pour chaque élément chargé, tu serais obligé de faire la conversion récursive de TOUS les éléments des listes.

Ce qui m'amène au problème principal

Pour ma couche de présentation, j'ai quasiment le même modèle mais avec des attributs supplémentaires qui sont initialisé lors de la créations des objets, ces attributs me permette d'améliorer et de gérer l'affichage.

Ton modèle objet est une structure pour représenter les données. Ces classes n'ont pas à savoir comment elles doivent s'afficher.
Ce que tu dois faire, c'est créer des classes qui savent utiliser ton modèle objet persisté pour pouvoir afficher les données qu'elles contiennent. Sinon, tu perds le principe de simple responsabilité des objets.
Une classe pour stocker, une classe pour sauvegarder, une classe pour afficher.

Plutôt que des créer des copies de ton modèle, fais en sorte de pouvoir le manipuler dans ta classe de présentation !




Sinon, tu peux aussi développer une autre couche d'interface qui permettra de faire la conversion entre les deux univers (donc celui-ci aura en dépendance ta classe de présentation et ta classe de persistance), mais les risques sont importants pour un gain limité.

[clecle]

Merci beaucoup pour cette réponse,


Donc je vais abandonner aussi cette architecture.

Mais quand tu parle de savoir manipuler dans la présentation, comment fait t'on pour manipuler un sous objet d'un graphe.
Parce que dans ma présentation le seul objet que je manipule est mon graphe qui contient mes sous-objets, mais jamais je n’appelle directement le sous-objet?


Merci

[eulbobo]

Mais quand tu parle de savoir manipuler dans la présentation, comment fait t'on pour manipuler un sous objet d'un graphe.
Parce que dans ma présentation le seul objet que je manipule est mon graphe qui contient mes sous-objets, mais jamais je n’appelle directement le sous-objet?

Ton objet graphe est un type de structuration des données. Sa seule raison d'être est de contenir (ou pas) des données à certains endroits bien précis, créant des relations entre les éléments. Chaque élément n'a pas à connaitre sa position dans le graphe et doit être indépendante de l'endroit où elle est positionnée, mais la position dans le graphe et les relations avec les autres que donne le graphe permettent d'obtenir d'autres propriétés.

Si tu dois accéder à certaines informations du graphe de manière simple, développe une facade !
Ta facade sait manipuler ta source de données, sait accéder aux informations, sait changer les noeuds.
Dans ta couche de présentation, appelles ta facade pour qu'elle fasse le travail à ta place à partir d'une source de données. C'est un graphe, mais en soit, la couche de présentation normalement, elle n'a pas besoin de savoir comment son stockées les données ni sous qu'elle forme. La couche de présentation, elle demande à la facade une liste de bidule et la facade lui donne sa liste.

Du coup tu aurais
Couche de présentation : interagit avec une/des facades pour avoir accès aux données et envoyer des éléments à modifier
Une facade : sait manipuler les données du graphe pour accéder aux données demandées par la facade, et sait exécuter les ordres que celle-ci lui donne
Une structure de données : ton graphe qui se contente de faire le graphe

Pour faire ça plus graphiquement, tu es le client d'un hotel et tu t'appelles Monsieur Présentation. Tu te présentes au comptoir (la facade), tu donnes ton nom... Le mec derrière le comptoir fait sa tambouille (que tu ne vois pas) et te donne ta clé. Comment il range ses clés, comment il retrouve la tienne, et comment il range ta clé une fois que tu lui redonne, c'est pas ton problème. Et c'est pas le problème de la clé non plus dont le rôle est d'ouvrir la porte. Et c'est pas le rôle non plus du casier de clés dont le rôle est de stocker les clés.

Donc non, ta couche de présentation ne manipule pas le graphe pour obtenir les informations dont elle a besoin, elle demande à quelqu'un de le faire pour elle !




Sinon, tu peux aussi faire en sorte que ta couche de présentation puisse savoir récupérer toute seule les informations dont elle a besoin dans le graphe, mais ça augmenterai le nombre de responsabilités de ta couche de présentation, donc ça augmenterai sa complexité pour pas grand chose.

[clecle]

Parfait j'ai tout compris.

Merci beaucoup

[MannCryss]

bjr a tous svp j sui novice en pogrammation jorai bsoin daide pour avoir un apercu dune représentation objet d'un site d'apprentissage de langue car jaimai bien en cree un site apprentissage de langue merci