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 ?

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

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

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

[cisco]

Je pense qu’il y a déjà un topic sur seam mais voici quelque réflexion :
En effet, JSF à besoin d’un « backing bean », et cela peut sembler « a prioris » overkills. Néanmoins cela permet à JSF de gérer la création et le cycle de vie de ce bean par rapport à la session HTTP et c’est donc utile.
Les annotations de seam permettent de transformer n’importe quel bean en « backing bean ». Ils utilisent souvent des EJB3 annoté pour en faire des « backing bean ».

Certain disent que ce n’est pas très propre, car l’EJB (business logic) est « polué » par des annotations du front-end. Moi je trouve que la simplicité à du bon, et la force des annotations est d’être comprise dans un contexte particulier et pas un autre. Par contre c’est dommage que ce soit du pur JBOSS et non une spécification (le JSR sur les web bean devrai arranger ça)

Pour ce qui est des DTO, ce n’est absolument pas nécessaire et surement pas recommandé avec JSF ! La manipulation des objets dans la page JSF peut se faire sans problème à partir du moment ou ces objets sont « détaché » de la transaction, ou alors si on est encore en transaction (« open session in view » pattern)

Pour l’alternative, je conseille maintenant de jeter un coup d’œil à ZK
Site ZK
http://www.zkoss.org/
demo ZK
http://www.potix.com/zkdemo/userguide/

En particulier, ZK permet d’utiliser un « spring resolver » pour les variables. Avec spring on peut donc aussi injecter n’importe quel bean de l’application et l’utiliser directement. ZK est vraiment minimaliste au niveau code nécessaire, et le backing bean est optionel.

[djo.mos]

Bonjour

En effet, JSF à besoin d’un « backing bean », et cela peut sembler « a prioris » overkills. Néanmoins cela permet à JSF de gérer la création et le cycle de vie de ce bean par rapport à la session HTTP et c’est donc utile.

Comment est ce possible qu'un framework Web Java puisse exister et fonctionner sans avoir des composants coté java, que ce soit les Actions/ActionForm de Struts ou encore les backing-beans de JSF ?
En quoi est ce du overkill ?

[cisco]

ca "semble" overkill, mais c'est nécessaire, on est d'accord. Sauf que pourquoi faire des classes supplémentaire à la place de réutiliser l'existant comme le fait seam.

[azerr]

Bonjour cisco,

Je ne connais pas JSF, mais je me permets de réagir à ce que tu as pu dire.

Certain disent que ce n’est pas très propre, car l’EJB (business logic) est « polué » par des annotations du front-end.

Si j'ai bien compris, tu appelles les methodes de tes EJB dans la page JSF?
Si c'est ca, je fais partie de ces personnes qui ne trouvent pas ca très propre.
La séparation en couche dans une application peut paraitre complique, mais elle permet de fonder les composants métiers de l'entreprise qui peut être réutilisé dans plusieurs applications (WEB ou Desktop).

Donc pour moi, les couches suivantes sont importantes :

• Couche contrôlleur : fait appel aux couches services. elle ne gérent NI le
  métier NI les accès aux données.
• Couche service : fait appel aux couches DAO (Acces aux données). Elle doit gérer le métier, mais ne doit jamais contenir des requetes à la base SQL, HBM....Concernant les transactions, ca peut etre cette couche qui initialise la transaction. Avec Spring, on peut avoir une couche service ou le code de la gestion des transactions n'est pas contenu dans celle-ci (voir AOP avec Cglib).
• Couche DAO : implementation de la DAO (JDBC, Hibrenate, JPA....).
  Le fait d'avoir une DAO permet de ne pas avoir un fort couplage à l'API utilisé pour les accès données dans les services.

Pour ce qui est des DTO, ce n’est absolument pas nécessaire et surement pas recommandé avec JSF ! La manipulation des objets dans la page JSF peut se faire sans problème à partir du moment ou ces objets sont « détaché » de la transaction, ou alors si on est encore en transaction (« open session in view » pattern)

Je ne connais pas JSF pour te contredire, mais utiliser les objets persistents dans la page peut paraitre simple mais je n'aime pas faire ca pour les raisons suivantes :

• penser à détacher tes objets. Il suffit que l'on oublie de detacher un objet et la c'est le festival.
• pour des cas simples, l'objet persistant peut suffire, mais pour des cas complexes (aggregation de plusieurs objets persistents), il faut souvent passer par une DTO. Donc ca veut dire que des fois on a un objet persistent et des fois on a un objet DTO.
• fort couplage avec la base de données. En effet si tu modifies ton schema, il faudra modifier surement ton objet persistent et du coup ta page JSP va etre aussi impacte. Si tu as passes par une DTO, c'est la couche service qui construit les DTO a parrtir des objets persistents qui sera impactes. La couche controlleur et View (JSP) ne sera pas impactes
• le pattern « open session in view » peut paraitre simple a premier abord, mais je ne le conseille pas, car il force l'application WEB a utiliser un filtre. Si on veut ensuite utiliser les couches services developpes dans une application Desktop, comment on fait?
  De plus pour la gestion d'erreur, c'est assez difficile a capturer correctement l'erreur. On peut router sur une page d'erreur, mais si on veut reafficher la page en mettant un joli message d'erreur, la ca devient plus complique.

J'espere que tu comprendras mes remarques.

Bonne journee

Angelo

[djo.mos]

ca "semble" overkill, mais c'est nécessaire, on est d'accord. Sauf que pourquoi faire des classes supplémentaire à la place de réutiliser l'existant comme le fait seam.

Ok. D'abord, il n'est pas nécessaire de faire des classes spécifiques pour les managed beans, et c'est là toute la beauté de JSF: il accepte des POJOs ordinaires (sauf bien sur les contraintes sur les getters+setters ainsi que la signatures de méthodes d'action).

Secundu, et là ça va enflammer encore le débat entre MVC/rigidité et souplesse (je suis du premier camp), je crois que c'est vraiment malsain d'exposer son code métier aux pages JSF. A moins que pour des applications vraiment basiques, les classes métier devront certainement dépendre de l'API JSF pour pouvoir effectuer des taches du genre:
- Créer des messages JSF
- Forcer la pagination d'un dataTable.
- Contrôler le flux de navigation (mais là, Seam essai de s'en sortir avec JBPM)
- Contrôle fine-grained des vues: quoi afficher, quoi désactiver, etc.
- etc

@+

[cisco]

Effectivement dans les exemples de seam on va voir, dans les EJB, des référence vers le framework JSF, et cela va donner de belle discutions dans les chaumières.
Par contre, il faut aller voir le nombre de ligne de code nécessaire pour faire une application pour se rendre compte de la force de ce framework.
Entre parenthèse pour azerr, La gestion d’erreur peut se faire avec des interceptor spring, ce qui permet d’avoir toujours le même comportement.
Et un DAO peut aussi être un service (c’est une idée que l’on trouve dans le livre « EJB in Action », que je trouve excellent, voir page 434 chapitre 12)

[manblaizo]

Je ne connais pas JSF pour te contredire, mais utiliser les objets persistents dans la page peut paraitre simple mais je n'aime pas faire ca pour les raisons suivantes :

• penser à détacher tes objets. Il suffit que l'on oublie de detacher un objet et la c'est le festival.
• pour des cas simples, l'objet persistant peut suffire, mais pour des cas complexes (aggregation de plusieurs objets persistents), il faut souvent passer par une DTO. Donc ca veut dire que des fois on a un objet persistent et des fois on a un objet DTO.
• fort couplage avec la base de données. En effet si tu modifies ton schema, il faudra modifier surement ton objet persistent et du coup ta page JSP va etre aussi impacte. Si tu as passes par une DTO, c'est la couche service qui construit les DTO a parrtir des objets persistents qui sera impactes. La couche controlleur et View (JSP) ne sera pas impactes
• le pattern « open session in view » peut paraitre simple a premier abord, mais je ne le conseille pas, car il force l'application WEB a utiliser un filtre. Si on veut ensuite utiliser les couches services developpes dans une application Desktop, comment on fait?
  De plus pour la gestion d'erreur, c'est assez difficile a capturer correctement l'erreur. On peut router sur une page d'erreur, mais si on veut reafficher la page en mettant un joli message d'erreur, la ca devient plus complique.

Bonjour azerr,
Je ne connais pas JSF non plus, mais j'aimerais aussi réagir parce que ça me semble être plus un problème d'architecture.
Je suis d'accord avec cisco sur le fait que les DTOs sont "overkill", parce que créer des objets pour être uniquement le mirroir des objets persistents peut très vite devenir difficile à maintenir. Il ne faut pas oublier que ce pattern DTO vient de l'époque EJB 2 et du fait qu'il n'était pas sain d'exposer ses entity beans à des remote clients, et que pour des raisons de performance les entity beans ne doivent présenter que des interfaces locales, être encapsulés derrière une Session Facade qui donc renvoie des DTOs aux couches présentation. Tout ça a l'air bien et permet de réduire le couplage entre les objets persistents et la couche présentation, comme tu l'as souligné.
Mais imaginons une application de taille moyenne avec, disons, une centaine d'objets persistents, et que pour chaque entité persistente on ait un ou deux objets DTO associés. Ensuite on a besoin d'ajouter du code pour créer et "populer" ces DTO à partir des entités persistentes, et là on fait appel à un autre pattern, le Transfer Object Factory, dont le rôle est uniquement de contenir de la logique pour créer des clones de nos objets persistents qu'on n'a pas envie d'exposer directement à la couche présentation.
On se retrouve donc avec trois arborescences de classes parallèles : les objets persistents, les DTOs, et les Transfer Object Factory. Pour une application avec une centaine d'entités persistentes, la maintenance de ce code parallèle devient vite un cauchemar. Je n'ose même pas imaginer ce que ça serait pour une application encore plus importante !!
Non, franchement, les DTOs utilisés dans ce seul but de découplage des couches introduisent bien plus de problèmes de maintenance encore.
C'est aussi une des raisons pour lesquelles les Entity Beans ont été abandonnés dans EJB 3 au profit de JPA, plus simple. Les beans persistent peuvent être transférés plus facilement vers la couche présentation sous forme d'objets détachés, et un framework comme Hibernate détache les objets de manière automatique, donc aucun risque "d'oublier" de le faire.
C'est certainement aussi la raison pour laquelle les ActionForm de Struts 1.x n'existent plus dans Struts2 où on peut directement agir sur l'objet model.
Cela dit, les DTOs restent importants pour les requêtes de reporting, où les données viennent d'une aggrégation de plusieurs entités, et à mon avis ça ne devrait servir qu'à ça et non pour des opérations de type CRUD.
Pour le reste, azerr, je suis entièrement d'accord avec la description que tu fais des différentes couches Controller, Service, DAO...
Voilà, c'est mon humble avis.

[azerr]

Bonjour manblaizo,

Merci beaucoup de ton analyse!
J'ai passe des heures et des heures a discuter sur le sujet DTO ou Objets persistents. Ta remarque est tres pertinente concernant la maintenance.

Mais la plupart des Transfer Object Factory peuvent etre genere (en partant d'un objet persistent, on peut generer la DTO mirroir). C'est sure que si il n'y a pas de generation, la c'est le cauchemard. On peut aussi utiliser des librairies comme Dozer pour faire les copies d'objet persistents en DTO, mais bon la je ne suis pas friand de cette solution, car one n emaitrise rien.

Il arrive souvent des cas ou tu veux enrichir les objet persistent. Par exemple j'ai developpe une application ou il devait y avoir des valeurs qui dependait d'un systeme d'unite. L'utilisateur pouvait modifier son systeme a tout moment. J'avais dont un getter geValue qui faisait la convesrion en fonction de l'unite selectionne. Dans mon cas j'ai utilise des DTO, mais si j'avais voulu utilise les objets persistents, il aurrait fallu que j'ajoute le code getValue dans les objets persistents, ce qui n'est vraiment pas terrible.

Mais bon je pense que le sujet DTO, objets persistents fera encore couler beaucoup d'encre.

Encore merci de tes remarques.

Angelo

[cisco]

Il arrive souvent des cas ou tu veux enrichir les objet persistent. Par exemple j'ai developpe une application ou il devait y avoir des valeurs qui dependait d'un systeme d'unite. L'utilisateur pouvait modifier son systeme a tout moment. J'avais dont un getter geValue qui faisait la convesrion en fonction de l'unite selectionne. Dans mon cas j'ai utilise des DTO, mais si j'avais voulu utilise les objets persistents, il aurrait fallu que j'ajoute le code getValue dans

le design pattern "adapter" aurai été bienvenu dans ton cas (et donc pas de DTO)

[manblaizo]

Il arrive souvent des cas ou tu veux enrichir les objet persistent. Par exemple j'ai developpe une application ou il devait y avoir des valeurs qui dependait d'un systeme d'unite. L'utilisateur pouvait modifier son systeme a tout moment. J'avais dont un getter geValue qui faisait la convesrion en fonction de l'unite selectionne. Dans mon cas j'ai utilise des DTO, mais si j'avais voulu utilise les objets persistents, il aurrait fallu que j'ajoute le code getValue dans les objets persistents, ce qui n'est vraiment pas terrible.

Mais bon je pense que le sujet DTO, objets persistents fera encore couler beaucoup d'encre.

C'est sûr que ce sujet, DTO vs. Objets persistents, va continuer à animer les débats. Je pense qu'il y a un juste milieu à trouver entre les deux en fonction des préoccupations que l'on met en avant pour son application : facilité de maintenance ou encapsulation totale des entités persistentes vis-à-vis de la couche présentation, ou autre.
En ce qui concerne l'exemple que tu as donné, pour ma part, la méthode getValue trouverait bien sa place dans l'objet persistent car c'est plus orienté objet; l'objet est le seul à connaître comment il stocke ses informations en interne et est donc le mieux à même de faire les conversions nécessaires pour renvoyer la bonne valeur au client.
Le but de toute la mouvance "tout POJO" actuelle, je pense, est bien de revenir aux fondamentaux de la conception orientée objet, avec des objets qui contiennent des données (attributs) et de la logique pour agir sur ces données (méthodes). Ceci parmettant d'enrichir les objets persistents et d'éviter donc d'avoir des objets anémiques (cf. Martin Fowler).
A+

[heid]

Je pense qu'il faut mettre de l'eau dans son vin au sujet des DTO. Ils peuvent être utiles en JSF pour des beans bien particulier. par contre, à mon sens, utiliser un dto pour un entitybean jpa contenant deux champs est inutile.

Pour en revenir à la question d'origine, JSF + EJB Session + EJB entity c'est pour moi exactement le modèle MVC. Certes le databinding JSF peut en dérouter certain mais on est encore loin de l'asp.net! JSF force le développeur à une certaine rigueure ce qui n'est pas un mal (cf .net), mais nécessite aussi de bien en comprendre le fonctionnement. En particulier au niveau du cycle de vie d'une requête JSF, sous peine de sanctions @immédiates (comprendra qui pourra).