beurk dans le cas de serveurs séparésEnvoyé par djo.mos
Perso, tout en lazy, pas de DTOs séparés, travailler dans un environnement managé (dans le cas de JPA) que ce soit dans un serveur d'application ou dans un conteneur web + Spring.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
beurk dans le cas de serveurs séparés
bonjour,
le sujet a dévié sur une discussion autour disign pattern le plus discuté. on ne peut toutefois associer JSF et DTO, JSF et un framework de présentation, qui, avec un controleur, le value binding, et des composants de présentation aide à avoir à avoir une architecture MVC2.
Pour ma part, avec hibernate et JSF, j'utilise plus le pattern Value object, qui est souvent confondu avec le DTO; et pour les formulaires qui sont exactement à l'image de l'objet de mapping OR, des formulaires pour faire des insert en base, je ne voi pa l'utilité d'avoir un objet de transfert.
article interessant de Martin Fowler qui répond à Jon Tirsen qui titrait sur son blog "Data Transfer Objects makes me sick! ".
Articles: Richfaces - JBosstools pour JSF.
Et avec comme contraintes EJB3 , jpa kodo, JSF1.1 sous weblo je fais commentPerso, tout en lazy, pas de DTOs séparés, travailler dans un environnement managé (dans le cas de JPA) que ce soit dans un serveur d'application ou dans un conteneur web + Spring.?
Tu fais comme preconiser par manblaizo, d'abord tu defini de quelles façon de chargé les objets tu aura besoins, imaginons que tu ai besoins pour 2 cas different de 1000 et de 1110 et bien tu fais deux methodes differentes l'une qui charge suivant 1000 et l'autre 1110 en essayant d'optimiser au maximum pour chaque cas (FETCH JOIN) (tu m'arrete si je dis une betise manblaizo). Par contre tu dois savoir de quoi tu aura besoins au prealable.FreshVic je fait comme toi au niveau des requêtes : je met majoritairement en lazy et je fais des namedquerries spéciales en fonction des cas d'utilisation avec des join fetch. Ca marche très bien pour un cas simple mais ca me pose problème dans une approche plus complexe d'un méchanisme "objet".
Pour le cas ou tu as un niveau de lien ca passe mais imagines un objet A qui est en *-* avec un B qui est en 1-* avec un C et en *-* avec un D. Lorsque tu charges A pour un traitement, tu dois prévoir 4 méthodes de chargement différentes???
1 = charge , 0 = ne charge pas
ABCD
1000 => que A sans relation
1100 => A et B
1110 => A et B et les relation de B vers C
1111 => Les 4 relations
Cela pose un grosse contrainte car parfois dans un appel de chargement tu ne sais pas encore jusqu'ou tu ira dans les relations, d'ou le lazy loading et donc le problème des requêtes n+1...
Le problème c'est que tout lazy ou tout eager me satisfait encore moins
Une idée?
Super pour une appli avec quatres tables, et quand j'ai 100 tables? Ca fait appeller du code super spécialisé pour chaque cas d'utilisation.tu fais deux methodes differentes l'une qui charge suivant 1000 et l'autre 1110
C'est pas toujours le cas ou alors tu mets du métier un peut partout dans tes classes de crud...Par contre tu dois savoir de quoi tu aura besoins au prealable
C'est vraiment un point qui me gène dans mes modélisations.
Oui, oui, c'est bien ça
C'est vrai qu'on dévie complètement là, et ça n'a plus rien à voir avec JSF ...
Je crois qu'on associe JSF auxx mauvaises pratiques car il est très flexible.
Je veux dire que dans Struts 1.x par exemple, le problème de DTO/pas DTO ne se pose même pas, car l'API de Struts est trop restrictif, dans la mesure où pour exposer des objets aux formulaires par exemple, il faut obligatoirement passer par ActionForm, ce qui impose la séparation avec les BO/DTOs.
Par contre, dans JSF, on peut utiliser directement un POJO tel quel, ce qui permet par exemple d'exposer ses BO/DTOs aux pages.
Ce n'est pas une mauvaise chose en soie, c'est à l'inverse un grand pas vers l'avant qui a été repris dans Struts 2 par exemple (et WebWork implicitement).
Seulement, si une personne fait une mauvaise utilisation de cette flexibilité, faut pas tenir JSF pour resposable et anti-design pattern !
C'est pas faux, les dto c'est du boulot et c'est pas toujours utile, mais je trouve qu'il raye 2 arguments trop rapidement "service layout" dont j'ai deja parler et rendre "remote" certaines applications.
Je vais me faire insulter, parce que nous sommes dans le forum JSF et que perso, je suis un recent convaincu que l'avenir du web est dans GWT, et avec gwt on en vient a un mode client serveur, les classe destiner a l'ihm sont compiler en javascript et se retrouve coté client, et je pense que compiler en javascript nos objets metier ( avec comportement) en javascript et les envoyer coté client est une erreur.
Effectivement DTO signifie Data Transfert Object , dans le cadre des application distribué on ne peut pas nier sont utilité.
Et bien je pense que bcp d'application vont migrer vers du GWT alors...
euh ... on parle déjà de JPA, et on est dans un environnement managé (Weblogic), alors où est le problème ?Et avec comme contraintes EJB3 , jpa kodo, JSF1.1 sous weblo je fais comment
Oui, mais tu n'as pas répondu à la question de heid: Si on a beaucoup plus que ces deux cas (et c'est pas du tout rare, avec un Domain Model suffisament riche, les combinaisons explosent).
Tu parles d'être en managé jusqu'a la couche présentation or, en JSF tu es hors contexte dans ton back bean => plus de lazy possible . Tu dois donc, savoir, lors de l'appel de ton ejb service quel sera à l'avance le niveau de granularité de que souhaite pour ta réponse.On est dans un environnement managé
Je viens de decouvrir cette façon de faire laisse moi un peu de temps pour y reflechir
Et bien je dirais qu'il faut pas faire toutes lesmethode de maniere exhaustive c'est une evidence.
J'ai pas de solution ideale, a par essayer une granularité moins fine par exemple 1100 est inclu dans 1110 et 1110 est inclu dans 1111, donc suivant le degrés d'optimisation, si l'optimisation t'es completement egale tu fais une unique methode 1111 si tu es un maniaque tu fait toutes les possibilité dont tu as besoins (mais comme tu le souligne le nombre de cas peut etre enorme) verdict : j'ai pas de solution ideale , il faut trouvé un juste milieu.
Pas vraiment, non.
Il faut que tu configures ton projet (tes DAOs) et WebLogic pour qu'il injecte un entityManager dans tes DAOs.
Il faut juste prendre soin d'annoter l'EntityManager comme d'habitude (PersistenceContext) mais en spécifiant le type comme Extended.
Oui mais la tu es dans un EJB session, moi je te parle du back bean JSF dans le conteneur web pas dans le serveur d'application donc en dehos du contexte de persistance. Tu n'aura pas d'injection @EntityManager dans un back bean JSF, c'est pourtant a ce moment que tu peux, par exemple, lister dans une datatable les lignes d'une commande (oups c'était du lazy loading => au revoir la commande ...).Pas vraiment, non.
Il faut que tu configures ton projet (tes DAOs) et WebLogic pour qu'il injecte un entityManager dans tes DAOs.
Il faut juste prendre soin d'annoter l'EntityManager comme d'habitude (PersistenceContext) mais en spécifiant le type comme Extended.
salut.C'est pas faux, les dto c'est du boulot et c'est pas toujours utile, mais je trouve qu'il raye 2 arguments trop rapidement "service layout" dont j'ai deja parler et rendre "remote" certaines applications.
Je vais me faire insulter, parce que nous sommes dans le forum JSF et que perso, je suis un recent convaincu que l'avenir du web est dans GWT, et avec gwt on en vient a un mode client serveur, les classe destiner a l'ihm sont compiler en javascript et se retrouve coté client, et je pense que compiler en javascript nos objets metier ( avec comportement) en javascript et les envoyer coté client est une erreur.
Effectivement DTO signifie Data Transfert Object , dans le cadre des application distribué on ne peut pas nier sont utilité.
Et bien je pense que bcp d'application vont migrer vers du GWT alors...
GWt et JSF ne sont pas très diffrents. c'est un peu comme les swing java basés sur les evenements. juste l'approche n'est pas la meme..
Articles: Richfaces - JBosstools pour JSF.
Et tu l'injecte à partir de la couche présentation ?
Franchement, j'aime pas, mais je suis dans un contexte EJB3 et ça implique une pratique différente que de l'hibernate directe.
En contre partie, je peux mettre ma couche EJB sur un autre serveur, voir plusieurs, et ça, c'est un plus !
Pour le problème des "1001", pareil, c'est pas "gérable"...
Je préfère (et de loin) utiliser la notion de granularité des "services"...
A+
(décidément, ça fait couler beaucoup d'encre, cool)
Ok. Tout d'abord, je n'ai jamais parlé et je ne parlerais jamais d'injecter un EntityManager dans un managed bean de JSF ! dieu m'en préserve, autant mourir dans un accident de circulation.
Ensuite, je ne sais pas pour Weblogic en particulier, mais perso, dans Tomcat + JPA + Spring, il suffit d'injecter l'EM dans les DAOs et d'appeler les méthodes de ces DAOs depuis les managed-beans de JSF par exemple. Je vois bien que dans Tomcat on reste toujours dans un meêm environnement, mais je sais pas pour WebLogic.
De plus, je fais gérer mes managed-beans par Spring au lieu de l'implémentation JSF, alors
Bref, faudrait se documenter sur l'Extended EM dans WebLogic ou utiliser Spring.
Et tu l'injecte à partir de la couche présentation ?
Franchement, j'aime pas, mais je suis dans un contexte EJB3 et ça implique une pratique différente que de l'hibernate directe.
En contre partie, je peux mettre ma couche EJB sur un autre serveur, voir plusieurs, et ça, c'est un plus !
Pour le problème des "1001", pareil, c'est pas "gérable"...
Je préfère (et de loin) utiliser la notion de granularité des "services"...
A+
(décidément, ça fait couler beaucoup d'encre, cool
Mais pourquoi tout le monde m'accuse de ça ? J'ai jamais dit ça ! J'ai bien dit injecter un EM dans les DAOs, jamais parlé de la couche présentation ...
Et je ne comprends pas le "Et tu l'injecte à partir de la couche présentation ?" ? A ce que je saches, l'EM est injecté par le serveur d'application ou par un framework tel que Spring par exemple, mais pas la couche de présentation ?
Je ne connais pas JSF , j'imagine qu'il s'agit effectivement d'un framework orienter composant certes mais je pense que la similitude s'arrete la.
GWT est completement orienté client , le code client devient a termes du javascript, du coup la difference est enorme puisqu'en JSF le code "client" s'execute coté serveur a titre d'exemple :
http://allen-sauer.com/com.allen_sau...rnetBlast.html
Trouve moi une implementation JSF de ce petit jeux, je penses pas qu'elle existe parce que je pense que ce jeux ne necessite pas de serveur, c'est juste un client developpé en GWT alors que JSF sans serveur a mon humble avis ca peut pas marcher. J'ai codé il y a pas longtemps un WebVNC , acceder a un poste distant dans votre navigateur en pur HTML et javascript aucun plugin aucun activeX aucune applet (Bientot sur sourceForge) et tout ca sans une seule ligne de javascript que du JAVA !!!
Tout ca pour dire qu'il y a une enorme difference sur la forme.
Lorsque tu fais une JSP classique (BEURK !!!
On est d'accord c'est pour ca que je disais : comment faire avec weblo, jpa ,jsf,ejb3.Bref, faudrait se documenter sur l'Extended EM dans WebLogic ou utiliser Spring.
Toi tu n'as pas de contexte EJB moi j'ai :Je vois bien que dans Tomcat on reste toujours dans un meêm environnement, mais je sais pas pour WebLogic.
DAO (EJB ENTITY) === SERVICe (EJB session) === WEB TIER (EX JSF) === JSP
de ta page jsp tu ne peux pas appeller directement ton controleur EJB Session mais passer par une action jsf qui elle renverra vers son controleur...
Répondre avec citation
Partager