Multi Results List

Hello,

Je me pose une petite question d'algorithmie. En effet, dans le cadre d'une recherche standard (via un terme alphanumérique), je dois ramener plusieurs listes d'éléments de nature différentes et les afficher dans une JSP (pour info. je fais du Struts 2).

Pour l'instant, voici comment je procède. Par exemple, je rentre le terme "pom" :

- Une action "BasicSearchAction" va devoir appeler un service BasicSearchService qui lui, va se charger d'appeler les BO->DAO de chaque types d'éléments comme par exemple : FruitBo, BoissonBo, DessertBo... Ce service va me construire un objet BasicSearchResult composé de listes hétérogènes, en l'occurence trois.

Ce BasicSearchResult est transmit à mon action, qui le met à disposition pour ma JSP.

Ainsi, pensez-vous qu'il s'agisse d'un algo. fiable ou y a t'il mieux d'après vous ?

Merci pour vos réponse,

Citation:

---

Envoyé par quarky

Ce service va me construire un objet BasicSearchResult composé de listes hétérogènes, en l'occurence trois.

---

Pourquoi 3 listes et pas une seule avec tous les objets dedans?

Because, je pense que c'est plus objet comme design, non ?
En outre, il faut bien à un moment ou un autre, devoir trier ces listes afin de les exposées dans ma JSP (sous forme de trois tables).

Ulrich

Citation:

---

Envoyé par quarky

Because, je pense que c'est plus objet comme design, non ?

---

Non, c'est pas plus ni moins objets. C'est juste plus "hierarchique"

Citation:

---

En outre, il faut bien à un moment ou un autre, devoir trier ces listes afin de les exposées dans ma JSP (sous forme de trois tables).

---

Ca c'est un traitement spécifique a cette JSP, ca n'a pas de rapport avec le "contrat" de ta methode BasicSearchResult(). Cette méthode n'est pas sensée savoir que ta JSP va faires des tables séparées suivant les types des objets. Elle renvoie juste une liste d'objets qui correspondent a ton critère.

J'ai vraiment du mal à me dire que travailler avec des objets hétérogènes dans une seule liste est "mieux", que d'avoir un objet a des propriétés dédiées à ces listes.

Citation:

---

Envoyé par quarky

J'ai vraiment du mal à me dire que travailler avec des objets hétérogènes dans une seule liste est "mieux", que d'avoir un objet a des propriétés dédiées à ces listes.

---

C'est comme ca que fonctionne le "SELECT" en SQL et personne ne s'en plaint. :aie:

Imagine maintenant que dans ta JSP tu veux afficher les résultats par ordre alphabetique, quelque soit le type. Tu fais comment ? Tu ecris une "autre" methode BasicSearchResult() ?

Citation:

---

C'est comme ca que fonctionne le "SELECT" en SQL et personne ne s'en plaint.

---

En fait, je suis dans le monde JEE avec de l'Hibernate derrière. Donc, même au niveau Data, je suis en objet.

Citation:

---

Imagine maintenant que dans ta JSP tu veux afficher les résultats par ordre alphabetique, quelque soit le type. Tu fais comment ? Tu ecris une "autre" methode BasicSearchResult() ?

---

Why not? Si c'est une demande d'évol. ! Le principe n'est t-il pas de répondre aux besoins de l'utilisateur à l'instant t ?

Citation:

---

Envoyé par quarky

En fait, je suis dans le monde JEE avec de l'Hibernate derrière. Donc, même au niveau Data, je suis en objet.

---

Dans Hibernate c'est pareil : Query.list() revoie une seule liste, meme si les objets sont hétérogènes.

Citation:

---

Why not? Si c'est une demande d'évol. ! Le principe n'est t-il pas de répondre aux besoins de l'utilisateur à l'instant t ?

---

Le principe en objet c'est l'encapsulation des données, la séparation des responsabilités et le respect du contrat.

Donc je ferai un "BasicSearchResult" qui renvoie une seule liste hétérogène List<Object>. Donc une responsabilité "base de données"

Et un "GroupByType" qui prend une List<Object> et retourne une liste de listes groupées par type. Donc une responsabilité "mise en forme"

Je comprends mais c'est curieux comme raisonnement pour moi. Quant à Hibernate, je n'ai jamais vu de HQL qui renvoyait des bean différents, faut que je look. En fait, tu pars du principe que pour un affichage de données standards, nul besoin d'avoir conteneur spécifique, mais seulement un conteneur d'objets quelconques. Et on délègue à la vue le soin de mettre en forme à sa convenance ?

Citation:

---

Envoyé par quarky

En fait, tu pars du principe que pour un affichage de données standards, nul besoin d'avoir conteneur spécifique, mais seulement un conteneur d'objets quelconques. Et on délègue à la vue le soin de mettre en forme à sa convenance ?

---

C'est ce que j'ai compris de ton problème. Tu as une responsabilité "modèle" qui est de faire une recherche sur plusieurs BO, et une responsabilité "vue" qui est de présenter les résultats par type. ;)

Oui, c'est ça.
Mais cette réflexion partait en fait d'un hypothétique problème d'optim. Car cette fameuse JSP sera notre main page et c'est pour cela que je me posait cette question. Il peut être intéressant pour moi de reconsidérer cette phase de dév. avec ce que tu proposes, qui est visiblement pour toi une solution instinctive ?

Merci

Citation:

---

Envoyé par quarky

Il peut être intéressant pour moi de reconsidérer cette phase de dév. avec ce que tu proposes, qui est visiblement pour toi une solution instinctive ?

---

C'est pas vraiment "instinctif". C'est plutôt la résultante de plusieurs années passées à faire des architectures, et a tirer leçons de mes erreurs. (si, si... j'essaye).

Ce que j'ai appris c'est qu'il vaut mieux faire un design simple et clair, puis ensuite ajouter "par dessus" des optimisations pour un cas particulier (cache, court-circuits, ...).

Faire un design optimisé pour un cas particulier, c'est prendre le risque de se retrouver piégé lors des futures évolutions/améliorations. Car s'il y a bien une constante, c'est que rien n'est jamais figé. :aie:

Merci pour tes conseils.
J'essaierai de faire un feedback sur ce forum à l'issu de mes investigations.

Ulrich