Discussion :

[alex00]

Bonjour

Ce point prete a discussion :

Les pojos ne doivent pas être pollués par le code applicatif.

(POJO : plain old java object).

Pour ma par, les POJO ont un comportement qui peut etre complexe, a ne pas confondre avec les DTO.
Mon expérience me montre qu'en info industrielle on a des POJOs complexes, et en info de gestion (dont le web en général) le code applicatif est en parti sorti de l'objet du domaine et mis dans des classes de service.

http://www.theserverside.com/pattern...hread_id=33387
anti pattern : anemic domain model

J2EE patterns: Transfert Object

avec un peu de méthode :
cas d'utilisations et user stories => classes de services (applicatives)
analyse => classes du domaine *avec des responsabilités*, donc 'un peu complexe'
conception => classes techniques et annotations

Alex

[azerr]

Bonjour,

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

Je ne vois pas trop comment ce pattern aurrait pu m'aider. Moi ce que je voulais c'est avoir une DTO et appeler dans la JSP le getValue sans que je fasse appel a d'autres classes avant qui me fassent la conversion.

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

Le probléme c'est que souvent les objets persistents sont générés à partir d'un schéma d'une BD ou à partir d'un modèle UML. Si on commence a mettre de la logique métier dans les objets persistents, on risque d'écraser la logique métier. Comment règle tu ce problème?

Angelo

[manblaizo]

Le probléme c'est que souvent les objets persistents sont générés à partir d'un schéma d'une BD ou à partir d'un modèle UML. Si on commence a mettre de la logique métier dans les objets persistents, on risque d'écraser la logique métier. Comment règle tu ce problème?

Bonjour,
Je crois que le modèle objet ne devrait pas être le total reflet du modèle relationnel, vu la grande différence entre les deux paradigmes. Générer les objets persistents à partir du schéma de la base de données peut être un bon point de départ, mais ce modèle objet devrait pouvoir être amélioré et enrichi par une analyse et une conception orientées objet et laisser l'outil ORM s'occuper du reste. Comme exemple, un modèle objet généré à partir du schéma relationnel ne comporterait à coup sûr aucune notion d'héritage et certainement pas de relations polymorphiques entre les entités persistentes, qui sont quand même des concepts auquels on arrive très facilement à partir d'une analyse du domaine que l'on essaie de modéliser pour une application de taille moyenne.
Evidemment l'idéal serait de partir du modèle objet et de l'adapter à la base de données par configuration de l'outil de mapping ORM afin de mieux profiter des avantages des deux mondes, objet et relationnel.
Je continue à penser que les objets persistents devraient pouvoir contenir plus de logique que les simples getter/setter. Mais il peut arriver qu'ils contiennent alors de la logique métier qu'on ne voudrait pas exposer à la couche présentation parce que trop sensible, et dans ce cas un DTO a toute sa place.
Il y a un juste milieu à trouver pour ce qui est de l'utilisation des DTOs, mais je crois que ça ne devrait plus être aussi systématique que ça l'était du temps des EJB 2 entity beans. ça devrait devenir l'exception et non la règle, et utiliser plus des objets détachés (en faisant attention aux lazy loading, bien entendu).
Voilà.

[heid]

manblaizo soulève implicitement une autre question (Insoluble a mon sens) qui fera elle aussi couler beaucoup d'encre : doit-on partir de la base de données pour générer les classes métier ou doit-on partir du métier pour générer la base de données...
En fait en y réflechissant bien ca impacte le débat DTO/ Pas DTO qui lui aussi est en relation avec la question initiale JSF anti pattern !

Je pense que ce sont plus des questions "philosophiques" et il n'y a pas réellement de bonnes ou de mauvaises pratiques, ca dépend beaucoup du projet et de la façon de travailler des acteurs de ce projet.

[djo.mos]

manblaizo soulève implicitement une autre question (Insoluble a mon sens) qui fera elle aussi couler beaucoup d'encre : doit-on partir de la base de données pour générer les classes métier ou doit-on partir du métier pour générer la base de données...

Ouep, en effet ...
Et profitant de cette occasion pour donner mon avis: Je hais l'approche DB->Objets, à moins bien sûr qu'on m'y force
Sérieusement, si on part de zéro, dans une application neuve, je ne vois pas pourquoi partir de la base de données si en fin de compte on travaille sur des objets et dans un langage objet. Partir de la base de données va générer des objets pas forcément les mieux adaptés au cas d'utilisations de l'appplication et non-optimisés comme l'a souligné manblaizo.

J'aime bien l'idée de considérer que la persistence est un artifact, un détail technique qui ne doit pas influencer ses choix, et qu'il faut plutôt se concentrer sur le coté applicatif.

[heid]

Je pense que c'est un compromi entre la logique métier (on part l'analyse UML ...) et des optimisations de la base (... mais on essaie de penser à ce que donnera le modèle BDD).

[djo.mos]

Ouep, c'est pas faux
Ce que j'avançais est une sorte d'utopie, d'idéal.
Pratiquement, on est bien limité pas libre à 100% lorsque on fait la conception du Domain Objects si on compte les persister avec un API tel que JPA par exemple. On se retrouve souvent en train de changer sa conception originale car ledit API n'accèpte pas nos graphes d'objets.
Espérons seulement que ça changera un de ses jours.

[heid]

si on compte les persister avec un API tel que JPA par exemple

même combat camarade !

[FreshVic]

Bonjour à tous, je tiens a m'excuser car je vais etre un peu hors du sujet de base "JSF" que je ne connais pas du tout.

Mais j'ai lu dans ce sujet certaines choses que je peux pas vraiment laisser passer, je peux pas laisser certaines remarque sans reponse, je veux parler des objet "metier" creux, de l' "anemic model".

Bonjour

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.

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.

Dire qu'il ne faut PAS mettre de la logique metier dans les objet METIER est une baeration, separer logique metier et données c'est revenir au procedurale, je ne jette la pierre a personne car bcp de projet utilise ce principe, service traitement + objet metier (données) , si ca c'est pas du procedurale ?????

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.

Un exemple simple , revenons aux bases de l'objet, imaginons une classe personnes, imaginons que nous ayons besoins de savoir si une personne à des enfants, pour faire cela , on peu imaginer que nous avons une collection ou un tableau d'enfant dans l'objet et donc on aurait une methode qui retourne true si la liste des enfants n'est pas vide.
Ou placer cette methode ? la reponse est DANS L'OBJET METIER Personne. Imaginons que dans une premiere implementation nous ayons utiliser un tableau d'enfants Personne[] enfants; si nous suivons votre ligne de conduite nous avons une classe de service pour la classe personne dans laquelle nous mettrons isParent et retourne true si le tableaux n'est pas vide. Mais en faisant ca vous etes obliger d'ouvrir l'implementation de la classe personne en gros vous mettez un getEnfants public dans personnes.
Les problemes sont multiple d'abord la personne qui implemente le service qui n'est pas forcement la meme que le developpeur de l'objet personne , se DOIT de connaitre l'implementation de personne et dois savoir que enfants est un array, ensuite les developpeur qui utiliserons Personne et qui ne voit pas de methode isParent dans Personne mais qui vois un array d'enfants se dise qu'il vont faire eux meme le test c'est facile getEnfant().lenght > 0 et hop le tour est jouer hop flagrant delis de duplication de code !!!!!
Autre probleme l'implementation change nous passons a un arraylist le test n'est plus le meme, il devient enfant.size()> 0 , en modifiant une petite chose dans personnes nous devons modifier plusieurs classe surtout si nous avons de la duplication de code.

Comment j'aurais fait ?
Simple une collection d'enfant private , pas de getters dessus, l'implementation est alors encapsuler (un des 3 grand principe de l'objet) dans personnes et une methode public isParent() qui contiendra l'unique version du code permettant de savoir si une personne a des parents ou non, et qu'on viennent pas me dire que ca pollu mon objet , ca le rend un peu moins stupide, et surtout ca evite de POLLUER une classe service qui effectivement contient de la logique metier mais avec une plus grosse granularité en utilisant les services de granularité plus fine rendu par les objet metier.

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+

Bonjour

Ce point prete a discussion :


(POJO : plain old java object).

Pour ma par, les POJO ont un comportement qui peut etre complexe, a ne pas confondre avec les DTO.
Mon expérience me montre qu'en info industrielle on a des POJOs complexes, et en info de gestion (dont le web en général) le code applicatif est en parti sorti de l'objet du domaine et mis dans des classes de service.

http://www.theserverside.com/pattern...hread_id=33387
anti pattern : anemic domain model

J2EE patterns: Transfert Object

avec un peu de méthode :
cas d'utilisations et user stories => classes de services (applicatives)
analyse => classes du domaine *avec des responsabilités*, donc 'un peu complexe'
conception => classes techniques et annotations

Alex

Content de voir que je suis pas le seul à penser cela , j'insiste sur le l'article de martin fowler qui est d'une verité a mon sens indiscutable.

Je suis pas sur d'avoir ete tres clair dans mon exemple, mais il est important que des debutants qui parcours le forum ne soit pas mal informé, en tout cas ils auront 2 point de vue ce qui donnera a reflechir.
Peut etre que je suis dans le faux et que l'avenir de l'objet est le procedurale mais pour le moment j'en suis pas du tout convaincu.

[djo.mos]

Bonjour.

Mais j'ai lu dans ce sujet certaines choses que je peux pas vraiment laisser passer, je peux pas laisser certaines remarque sans reponse, je veux parler des objet "metier" creux, de l' "anemic model".


Dire qu'il ne faut PAS mettre de la logique metier dans les objet METIER est une baeration, separer logique metier et données c'est revenir au procedurale, je ne jette la pierre a personne car bcp de projet utilise ce principe, service traitement + objet metier (données) , si ca c'est pas du procedurale ?????

Ok, je comprends parfaitement ton point de vue (celui de Martin Fowler aussi ainsi que celui de Gavin King ), mais je dois te clarifier un truc: il ne s'agit pas ici de faire du SmallTalk moins encore d'être des puristes: faire de l'orienté objet pur et dur !
Nous faisons du JavaEE, et pour faire cela, nous utilisons des framework (Hibernate, JPA, JSF, JTA, JMS, etc.).
Ces frameworks bien qu'ils facilitent de nombreuses taches, impliquent aussi des limitations et des contraintes sur la façon de code son application.
Le retour d'expérience de nombreuses equipes de développement et d'autres projets à l'echelle d'entreprises ont permis de mettre en place des BluePrints, des solutions types à utiliser pour ne pas mourir jeune en essayant de mettre en place une application, comme par exemple le patterns classiques (DTO/DAO, Facade, etc.).
Si on s'amusait vraiment à combiner la logique et les données (comme l'encourage la POO à juste titre d'ailleurs), je me retrouverais en train de me battre avec les frameworks sous jacents qui iomposent un format particulier à mes classes.

Un exemple simple , revenons aux bases de l'objet, imaginons une classe personnes, imaginons que nous ayons besoins de savoir si une personne à des enfants, pour faire cela , on peu imaginer que nous avons une collection ou un tableau d'enfant dans l'objet et donc on aurait une methode qui retourne true si la liste des enfants n'est pas vide.
Ou placer cette methode ? la reponse est DANS L'OBJET METIER Personne. Imaginons que dans une premiere implementation nous ayons utiliser un tableau d'enfants Personne[] enfants; si nous suivons votre ligne de conduite nous avons une classe de service pour la classe personne dans laquelle nous mettrons isParent et retourne true si le tableaux n'est pas vide. Mais en faisant ca vous etes obliger d'ouvrir l'implementation de la classe personne en gros vous mettez un getEnfants public dans personnes.
Les problemes sont multiple d'abord la personne qui implemente le service qui n'est pas forcement la meme que le developpeur de l'objet personne , se DOIT de connaitre l'implementation de personne et dois savoir que enfants est un array, ensuite les developpeur qui utiliserons Personne et qui ne voit pas de methode isParent dans Personne mais qui vois un array d'enfants se dise qu'il vont faire eux meme le test c'est facile getEnfant().lenght > 0 et hop le tour est jouer hop flagrant delis de duplication de code !!!!!
Autre probleme l'implementation change nous passons a un arraylist le test n'est plus le meme, il devient enfant.size()> 0 , en modifiant une petite chose dans personnes nous devons modifier plusieurs classe surtout si nous avons de la duplication de code.

Comment j'aurais fait ?
Simple une collection d'enfant private , pas de getters dessus, l'implementation est alors encapsuler (un des 3 grand principe de l'objet) dans personnes et une methode public isParent() qui contiendra l'unique version du code permettant de savoir si une personne a des parents ou non, et qu'on viennent pas me dire que ca pollu mon objet , ca le rend un peu moins stupide, et surtout ca evite de POLLUER une classe service qui effectivement contient de la logique metier mais avec une plus grosse granularité en utilisant les services de granularité plus fine rendu par les objet metier.

Mauvais exemple: c'est pas de la logique métier ça, et ça peut parfaitement être intégré dans un DTO sans le moindre risque, à condition bien sur de l'annoter avec @Transient si on utilise JPA par exemple.

Ce que je désigne par logique métier est un tout petit peu plus compliqué que ça, et un traitement pareil ne se contente généralement pas des données relatives à une seule entité: au contraire, il doit aller chercher d'autres données du Repository, les combiner, y appliquer des conditions, des transformations et des traitements pour enfin décider de la suite.
Je t epose donc la question: ça te parait logique/préférable d'inclure un tel traitement dans une classe porteuse de données Personne par exemple ?

Je suis pas sur d'avoir ete tres clair dans mon exemple, mais il est important que des debutants qui parcours le forum ne soit pas mal informé, en tout cas ils auront 2 point de vue ce qui donnera a reflechir.
Peut etre que je suis dans le faux et que l'avenir de l'objet est le procedurale mais pour le moment j'en suis pas du tout convaincu.

Comme je l'ai dis avant, il ne s'agit pas ici de purisme: il faut être pragmatique et ouvert: si dans un cas particulier le procédural est mieux adapté, alors j'opte pour le procédural sans hésiter.

[azerr]

Bonjour FreshVic,
merci de intervention. J'ai bien compris ton point de vue et de la grosse bete de Martin Fowler. Mais je reviens sur mon cas ou je travaille sur un enorme projet ou la base change tout le temps car les besoins des clients changent tout le temps. Les objets persistents sont générés à partir d'un plugin (developpe en interne) qui genere les objets persistents et les patchs SQL. Cela fait gagner un temps monstrueux. Du coup dans mon cas je ne peux pas mettre de code métier dans les objets persistents.

Beaucoup d'outils de generation de code se comporte de cette facon (Hibernate de JBoss...). Penses tu qu'ils ont une mauvaise approche?

Angelo

[FreshVic]

Mauvais exemple: c'est pas de la logique métier ça, et ça peut parfaitement être intégré dans un DTO sans le moindre risque, à condition bien sur de l'annoter avec @Transient si on utilise JPA par exemple.

Ce que je désigne par logique métier est un tout petit peu plus compliqué que ça, et un traitement pareil ne se contente généralement pas des données relatives à une seule entité: au contraire, il doit aller chercher d'autres données du Repository, les combiner, y appliquer des conditions, des transformations et des traitements pour enfin décider de la suite.
Je t epose donc la question: ça te parait logique/préférable d'inclure un tel traitement dans une classe porteuse de données Personne par exemple ?

Comme je l'ai dis avant, il ne s'agit pas ici de purisme: il faut être pragmatique et ouvert: si dans un cas particulier le procédural est mieux adapté, alors j'opte pour le procédural sans hésiter.

J'ai voulu faire un exemple simple, je suis pas un expert en redaction et je voulais pas me noyer dans mes explications, mais je comprend ton point de vu, ceci dit tu disais ne mettre QUE des getters et des setters dans tes objets metier donc isParent ou encore ajouterEnfant ne pouvait pas etre dans tes objets metier.

Pour en revenir a ta question, ma reponse est "ca depend" c'est ce que je voulais dire par "granularité" les objet metier on une logique metier a granularité fine, ensuite si tu as du metier complexe qui necessite la combinaison de plusieurs objets metiers et bien tu la sors dans une classe service encore que si dans le graphe d'objet tu as les info qu'il te faut ca me choquerais pas de le mettre dans l'objet metier mais je comprendrais que ca choques certaines personnes car parfois les graphes d'objet son enorme et du coup on pourrait tout mettre dans l'objet "racine" et ca ne serais evidement pas la solution.

Un autre exemple simpliste: une classe Aeroport qui contients des Avion Avion possede la methode decoller (qui mieux que l'avion sait comment decoller? ), l'aeroport fait decoller les avions, l'objet racine Aeroport utilise certains objets de son graphe d'objet en l'occurence avion pour effectuer sont "travaille" pourquoi sortir le decollage dans une classe service ??

Par contre une logique metier complexe qui mets en jeux n objets metier qui n'ont aucun liens il faut, a mon avis, la sortir dans une classe service.

Je connais moi aussi le probleme d'adherence au framework technique, pourtant il fautl'eviter au maximum, il faut bien comprendre que leplus important dans une application c'est le modele "domaine metier" c'est ce qui est le plus reutilisable , c'est ce qui a le plus de valeurs, les framework technique evolue et/ou disparraissent la logique metier reste.
Je sais c'est dur a entendre quand on est technique, mais la technique est bien plus ephemere que le metier, donc un bon modele vaut bien plus que de bons frameworks.

Personnellement je pense qu'il vaut mieux eviter le procedurale, faire une bonne analyse et ensuite s'arranger pour choisir les frmawork technique qui permettront de respecter le modele.

Bonjour FreshVic,
merci de intervention. J'ai bien compris ton point de vue et de la grosse bete de Martin Fowler. Mais je reviens sur mon cas ou je travaille sur un enorme projet ou la base change tout le temps car les besoins des clients changent tout le temps. Les objets persistents sont générés à partir d'un plugin (developpe en interne) qui genere les objets persistents et les patchs SQL. Cela fait gagner un temps monstrueux. Du coup dans mon cas je ne peux pas mettre de code métier dans les objets persistents.

Beaucoup d'outils de generation de code se comporte de cette facon (Hibernate de JBoss...). Penses tu qu'ils ont une mauvaise approche?

Angelo

En fait ca rejoins ce que je viens de dire, selon moi le plus important est le modele metier, les framework technique sont certes interessant augmente la productivité mais si il ruine le modele metier ils sont a jeter ou du moins (dans ton cas) a utiliser differement, car loin de moi l'idée de jeter hibernate, je pense qu'hibernate est assez souple, mais je reocnnais qu'il est difficile d'eviter completement l'adherence à hibernate.

Augmenter la productivité de depart au depend d'un modele stable sur le long termes donc en theorie plus simple a maintenir est selon moi une erreur, tout depend du projet , de sa durée de vie et de la valeur que vous donnez au metier.

Encore une fois je n'ai pas la science infuse, chaque projet a sa specificité, je ne connais pas vraiment les spécificités de vos projet, je donne juste un avis externe.

[manblaizo]

Par contre une logique metier complexe qui mets en jeux n objets metier qui n'ont aucun liens il faut, a mon avis, la sortir dans une classe service.

Je suis tout à fait d'accord, et d'ailleurs quand on lit bien l'article de Fowler (que je recommende encore une fois), il dit que dans ce cas la couche service devrait être fine et jouer plutot un rôle de coordination.

Je connais moi aussi le probleme d'adherence au framework technique, pourtant il fautl'eviter au maximum, il faut bien comprendre que leplus important dans une application c'est le modele "domaine metier" c'est ce qui est le plus reutilisable , c'est ce qui a le plus de valeurs, les framework technique evolue et/ou disparraissent la logique metier reste.
Je sais c'est dur a entendre quand on est technique, mais la technique est bien plus ephemere que le metier, donc un bon modele vaut bien plus que de bons frameworks.

Personnellement je pense qu'il vaut mieux eviter le procedurale, faire une bonne analyse et ensuite s'arranger pour choisir les frmawork technique qui permettront de respecter le modele.

Encore d'accord, et justement, si les EJB 2 CMP Entity beans étaient de plus en plus abandonnés par les développeurs au profit de frameworks plus flexibles tels que Hibernate, c'est justement à cause de la rigidité de ces mêmes entity beans qui imposaient un model procédural et surtout ne permettaient pas de mettre en ouevre un model du domaine plus enrichi par les concepts objet (héritage, polymorphisme ...). Et voir ce modèle d'Entity beans abandonné dans EJB 3 au profit de JPA est bien un exemple qui vient étayer ce que dit FreshVic, que les frameworks sont là pour évoluer ou disparaitre au profit d'autres mieux adaptés, mais par contre les problèmes METIER que l'on tente de résoudre restent les mêmes.

En fait ca rejoins ce que je viens de dire, selon moi le plus important est le modele metier, les framework technique sont certes interessant augmente la productivité mais si il ruine le modele metier ils sont a jeter ou du moins (dans ton cas) a utiliser differement, car loin de moi l'idée de jeter hibernate, je pense qu'hibernate est assez souple, mais je reocnnais qu'il est difficile d'eviter completement l'adherence à hibernate.

Augmenter la productivité de depart au depend d'un modele stable sur le long termes donc en theorie plus simple a maintenir est selon moi une erreur, tout depend du projet , de sa durée de vie et de la valeur que vous donnez au metier.

Tout à fait d'accord.
Et pour répondre un peu à azerr, je crois qu'il est normal que la base de données change fréquemment lors des premiers cycles d'un projet, c'est à ce moment que les besoins utilisateurs changent le plus. Mais à partir d'un certain nombre de cycles, et à mesure que l'on approche la phase de déploiement, l'architecture de l'application se stabilise et les besoins ne varient que peu, en tout cas, des changements à la marge, pas susceptibles de modifier encore complètement l'architecture, sinon cela voudrait dire qu'on était parti sur des bases complètement fausses et qu'on développait tout à fait autre chose.

[OButterlin]

Juste une petite chose en passant pour justifier les DTO...

Il ne faut pas oublier que les EJB fonctionnent dans un conteneur d'EJB.
Lorsqu'un EJB "retourne" à la couche de présentation, il est détaché.
Dans ce contexte, impossible d'utiliser un lazy loading, et pour ce qui est de mettre toutes les relations en EAGER, priez pour que le volume ne soit pas trop important et dans bien des cas, bonjours les performances !
D'où l'intéret des DTO, ils sont alimentés par la couche EJB et représentent les données présentent dans l'ihm.
Libre à la couche de présentation de les formater de telle ou telle manière.

Donc, pour moi, vive les DTO !

[manblaizo]

Juste une petite chose en passant pour justifier les DTO...

Il ne faut pas oublier que les EJB fonctionnent dans un conteneur d'EJB.
Lorsqu'un EJB "retourne" à la couche de présentation, il est détaché.
Dans ce contexte, impossible d'utiliser un lazy loading, et pour ce qui est de mettre toutes les relations en EAGER, priez pour que le volume ne soit pas trop important et dans bien des cas, bonjours les performances !
D'où l'intéret des DTO, ils sont alimentés par la couche EJB et représentent les données présentent dans l'ihm.
Libre à la couche de présentation de les formater de telle ou telle manière.

Donc, pour moi, vive les DTO !

Non, je ne pense pas que les EJB justifient l'utilisation des DTO, en tout cas tant qu'on n'est plus dans l'ancienne version EJB 2. Si tu utilises JPA en EJB 3, tu peux faire en sorte que tes Entities soient Serializable et donc puissent traverser les couches, rendant inutile le DTO, dans ce cas.
Quant au problème du lazy loading, il faut évidemment éviter de mettre les relations en EAGER loading, mais en fonction du cas d'utilisation, mettre en oeuvre une requête JPAQL avec "join fetch" pour charger l'ensemble des informations dont on a besoin pour le rendu de la vue.
Les DTOs restent importants, comme je l'ai déjà dit, mais on devrait maintenant essayer d'abandonner un certain nombre de vieilles pratiques héritées des EJB 2 Entity Beans tant décriés.

[cisco]

Et quand un ejb3 est référencé dans la couche présentation, celui ci bénéficie de la transaction “container manager” associé. C’est pourquoi déclarer un DAO (maintenant appelé EAO) en tant que EJB session est une bonne idée.
Avec Seam, il y a un mécanisme plus complexe qui pourrait mettre tous le monde d’accord:
Seam managed transactions

D’un point de vue pratique les DTO entrainent des duplications de code, et la duplication de code sur de gros projet c’est le cauchemar. En gros je vote contre les DTO!

[OButterlin]

Si tu utilises JPA en EJB 3, tu peux faire en sorte que tes Entities soient Serializable et donc puissent traverser les couches, rendant inutile le DTO, dans ce cas.

Le problème n'est pas là à mon sens, effectivement on peut leur faire traverser les couches du moment qu'ils implémentent Serializable, mais quand on a un modèle de données avec des références croisées dans tous les sens et un volume conséquent, là, le lazy loading n'est plus une notion abstraite, mais bel et bien une nécessité (c'est du vécu tout frais).
L'alternative que je verrais, serait de faire n implémentations d'EJB CMP en fonction des vues cibles, mais je pense que ce serait pire que tout
Et enfin, demander un contexte de persistance côté couche présentation ne me semble pas terrible non plus (séparation des rôles) et génèrerait (dans certains cas) un transit entre conteneur important.

Ce qui est intéressant dans ce débat, c'est les différences d'approche de chacun en fonction de leur "vécu" et à tout lire, on se rend compte que la solution idéale n'existe pas encore (dirait-on)

[heid]

L'alternative que je verrais, serait de faire n implémentations d'EJB CMP en fonction des vues cibles

Lorsqu'un EJB "retourne" à la couche de présentation, il est détaché.
Dans ce contexte, impossible d'utiliser un lazy loading, [...] D'où l'intéret des DTO, ils sont alimentés par la couche EJB et représentent les données présentent dans l'ihm

Je n'ai jamais implémenté de DTO et donc j'essaie de comprendre. Tu crée tes DTO et tu dis que c'est super car, créés sur le serveur, ils utilisent le lazy loading pour récurérer les données. Mais une fois en dehors du contexte, avec tes dto c'est évidement impossible d'utiliser le lazy loading. Donc, c'est bien dans ton service que tu dois réfléchir en fonction du type de demande si tu dois renvoyer telle ou telle information liée. Donc tu as le même problème des n implémentations cité ci-dessu. non?

[OButterlin]

Euh, pour moi, ce sont les DAO qui utilisent le lazy loading (et là, j'inclu le bean métier).
Le DTO n'est qu'une "vue" des DAO (partie "metier") mais ils sont conçus en fonction de l'utilisation finale (donc l'ihm)
Effectivement, ils sont créés dans le conteneur d'ejb et implémentent Serializable pour "voyager"

Ceci dit, sur la terminologie, on peut encore discuter... il y a certainement des puristes qui ne seront pas de mon avis

[azerr]

Comme dit OButterlin, le debat est en effet interessant.
J'ai eu moi meme une tres mauvaise experience avec un projet sans DTO (j'utilisais Hibernate). Au debut du projet tout se passait dans le meilleur des mondes, et c'etait un vrai bonheur. Mais au fil des années le modèle de données est devenu tres complexe et chaque developpeur qui arrivait sur le projet (qui etait un tres gros projet), ajoutait ses references et plus on avancait dans l'application plus elle devenait lente.

Concernant le lazy loading c'est super seduisant mais c'est super dangeux aussi. Hibernate a ces debuts etait repute lent, mais c'etait du a l'utilisation abusive du mode lazy. En ce qui me concerne je m'interdis le mode lazy. Dans un gros projet, ou l'on ne maitrise pas le code de l'autre developpeur, le mode lazy peut etre super dangereux, et ca ne force pas l'utilisateur a se poser les bonnes questions.

Moi le premier, je voies un getRoles qui est sur un objet Utilisateur, j'en ai besoin, je l'appelle. Je veux afficher la liste des utilisateurs et afficher la liste des roles, et la je me tappe le probleme du select n+1 sans m'en rendre compte. Au debut ca passe, mais une fois l'application installée chez le client, l'application rame et la pour detecter le problème ou la BD est complexe, c un peu chaud.

Il faut voir un projet evoluer dans le temps. Au debut la conception sans DTO peut paraitre etre tres seduisante, mais au fil du temps le graphe d'objet s'enrichit et les donnees renvoyees sont tres fortement lié à la base de données et ce graphe devient conséquent. Je comprends la retitence de certain qui se disent que de faire des copies d'objets persistents vers des DTO soientt horrible, mais ces copies doivent etre generees.

J'espere que ma petite expérience fera avancer le debat.

Angelo