Discussion :

[threshold]

Salut,

je commence à étudier JSF pour peut être l'utilisé dans une Appli.
j'ai vu qu'on pouvait faire un binding entre une dataTable et un Bean. Mais il faut rajouter un attribut UIData dans le Bean !!! Est-ce raisonnable de faire une chose pareil ? Cela ne conduit-il pas à un lien "trop" fort entre la partie métier et le framework JSF ? Ou alors il faut utiliser des DTO ce qui est à mon avis autant "Anti-pattern" que le lien précité!

Enfin je pense que c''est plutôt une mauvaise chose mais peut être ça ne l'est pas. Le fait que UIData peut être "rendu" sous différente forme n'y change rien à mon avis.

[paco30]

Il faut faire la différence entre un bean métier (Client, Article, Facture ....) et un backing-bean qui n'est qu'une projection de l'interface utilisateur côté serveur. Ce backing-bean comporte des références sur certains composants de l'ihm avec lesquels on veut interagir, par exemple un UIData pour une datatable.
Ce qui est commun aux deux, c'est qu'ils sont tous deux des managed-beans. Typiquement, le backing-gean joue le double rôle de contrôleur et de vue, et si l'on veut soigner la conception, on crée une classe vue qui rassemble les composants jsf, alors que dans le backing-bean contrôleur on se contente de recevoir les actions et les événements. Le contrôleur reçoit actions de l'utilisateur, récupère éventuellement des valeurs saisies dans la vue, interagit avec le modèle, et redirige vers une page résultat, qui elle-même récupère les valeurs du modèle mis à jour. On est bien en présence d'une architecture MVC.

[phpmad]

certe On reste dans une vision MVC mais, comment justifier cette duplication des objets, ex: Un objet métier Account avec toute la logique qu'on veut..et un autre objet AccountBean qui va contenir,en gros, les mêmes attributs moins les fonctions de l'objet Account ?

J'essaye de comprendre où se trouve "l'idéal" dans un modèle pour une WebApp de taillle moyenne. Apparement JSF est très apprécié par la communauté Java mais je reste sceptique. L'ennui est quoi prendre à la place de JSF ?

[paco30]

certe On reste dans une vision MVC mais, comment justifier cette duplication des objets, ex: Un objet métier Account avec toute la logique qu'on veut..et un autre objet AccountBean qui va contenir,en gros, les mêmes attributs moins les fonctions de l'objet Account ?

J'essaye de comprendre où se trouve "l'idéal" dans un modèle pour une WebApp de taillle moyenne. Apparement JSF est très apprécié par la communauté Java mais je reste sceptique. L'ennui est quoi prendre à la place de JSF ?

On constate qu'un conception saine et conforme aux design-patterns implique plusieurs couches: DAO, Présentation, Métier, Persistance ...
De plus, il peut sembler, en effet, qu'il y ait redondance entre des attributs Metier et Presentation.
En effet, cette redondance est nécessaire, songeons par exemple aux erreurs de validation qui ont pour conséquence de re-présenter la vue, celle ci comportant des champs déjà saisis, ainsi que des champs erronés pour correction.
La structure et l'état de l'objet Vue n'est donc pas complètement identique à l'état la structure de l'objet Métier.
De plus, la Vue représente, très souvent, une association de plusieurs objets Metier.
On retrouve donc dans un bean de type Vue des attributs identiques à ceux d'un bean Metier pur, mais c'est justifié.
On multiplie les classes, mais on systématise et on assainit l'architecture applicative par la mise en oeuvre des design-patterns, ces dernier ne constituant, on peut le concéder, pas un solution minimaliste, mais une solution robuste et éprouvée.

[djo.mos]

Bonjour

Salut,
j'ai vu qu'on pouvait faire un binding entre une dataTable et un Bean. Mais il faut rajouter un attribut UIData dans le Bean !!! Est-ce raisonnable de faire une chose pareil ? Cela ne conduit-il pas à un lien "trop" fort entre la partie métier et le framework JSF ? Ou alors il faut utiliser des DTO ce qui est à mon avis autant "Anti-pattern" que le lien précité!

Je pense surtout que tu confonds pas mal de notions là.
Par exemple, pour le binding d'une DataTable avec un UIData, UIData n'a pas le moindre lien avec la couche métier, c'est un composant GUI qui représente une DataTable, tout comme JTable dans Swing.

Dans swing, tu ne travailles que sur la JTable, tandis qu'en JSF, dans 95% des cas, tu ne toucheras pas à la représentation Objet du composant et le binding que tu décris comme "il faut" est en fait optionel et pas nécessaire la majorité du temps.

Bref, ne le prends surtout pas mal, mais je pense qu'il vaudrait mieux approfondir ses connaissances en JSF avant de tirer des conclusions hâtives

ex: Un objet métier Account avec toute la logique qu'on veut..et un autre objet AccountBean qui va contenir,en gros, les mêmes attributs moins les fonctions de l'objet Account ?

Décrite de cete façon, cette archi ne tient pas la route, je te l'accorde
Mais en réalité, ce n'est pas comme ça qu'on procède. On crée les entités qui représentent le domaine (User, Account, Article, etc.) qui sont des simples javabeans tout simples : des champs + getters + setters. (Ces beans peuvent correspondre aux DTOs).
Ensuite, on crée un ensemble d'objets qui permettent de retrouver et d'agir sur ces entités (c'est le Repository). En général, cette couche correspond aux DAOs qui offrent le CRUD sur ces entités depuis et vers une base de données.)
Au dessus de tout ça, on batit une couche services qui offre des fonctionnalités front-end et de haut-niveau. Ces fonctions combinent génralement plusieurs appeles aux fonctions des DAOs + de la logique.

Enfin, on crée ss vues et ses contrôleurs. Les controleurs interceptent les commandes générés par les vues, appèllent les services correspondants.

N.B.: Cette dernière partie n'a rien à voir avec JSF: ce sont des meilleurs pratiques dans le monde Java et qui peuvcent aussi bien être utilisé avec JSF qu'ave Struts ou WebWork etc.

Cordialement.

[threshold]

Bref, ne le prends surtout pas mal, mais je pense qu'il vaudrait mieux approfondir ses connaissances en JSF avant de tirer des conclusions hâtives

Je ne le prend pas mal , pourquoi je le ferais d'ailleurs, on est là pour apprendre aussi . Par contre je ne tire aucune conclusion dans mes propos.

Justement, la couche service si elle est codée de manière séparée des objets métier on se retrouve avec de la programmation pas tout a fait "Objet" puisque on sépare la logique des données...alors même que l'idée originel du paradigme objet stipule le rassemblement des données et les traitements qui leurs sont liés dans des classes "hérmetiques". Mais je suis d'accord sur le fait qu'on programme pas de la même manière une WebApp et un application de bureau.

Donc si je comprends bien, selon vous DTO, décrit par certain comme un anti-pattern, est en fait un bon pattern.

Le mieux est encore de "coder" et de voir par la suite où se trouve le couac afin de le corriger, si c'est possible.

merci pour vos commentaires messieurs

[djo.mos]

Bonjour.
En fait, DTO = Data Transfer Object, selon le pattern, est destiné à transférer les données entre les diverses couches de l'application. Par exemple, de la base de données vers la couche service ou même vers le contrôleurs.
Si on incluait de la logique dans les DTOs, ça casserait toute l'architecture et la séparation en couches de l'application vu que des fonctionalités spécifiques à une couche se retrouvent exposées aux autres.

[threshold]

Actuellement je boss sur une WebApp dont la logique est malheureusement codée dans des "controlleurs" servlet. Ceci rend impossible toute réutilisation de ce code dans une autre application, par ex: une appli de bureau qui manipulerait les mêmes objets que la WebApp ( en créant des entrées dans la base, récupérant des objets...etc ). En ce moment je suis obligé de refaire la quasi totalité de la logique dans un connecteur. Donc duplication du code et double maintenance (correction, evolution) dans deux projets en parrallèle.

C'est pour cette raison là que je me suis dis pourquoi pas intègrer la logique dans les POJOs et du coup je n'aurais plus qu'a "exporter" ces POJOs dans un JARs et c'est tout...

[paco30]

C'est pour cette raison là que je me suis dis pourquoi pas intègrer la logique dans les POJOs et du coup je n'aurais plus qu'a "exporter" ces POJOs dans un JARs et c'est tout...

Il serait préférable de déléguer la logique applicative dans des classes contrôleur bien séparées des pojos, ces derniers ne comportant que des attributs et les getters et setters associés. Les pojos ne doivent pas être pollués par le code applicatif.
Essaie de recycler chaque servlet en classe java simple, et gère le tout dans une classe façade qui centralise le tout.