Discussion :

[zadrov_nicolai]

Bonjour,
Je suis entrain de développer une application JAVA EE et j'ai pas encore décidé de ce qui est architecture applicative. Je vois que beaucoup de développeurs optent pour la combinaison de JSF (couche présentation) et SPRING (couhe métier).

Je voudrai savoir quel est l'interet de cette combinaison ? si j'utilise JSF+SPRING au lieu de SPRING MVC+SPRING , qu'elle avantage présentera il pour mon application ?

Merci.

[tchize_]

J'irais moi plus loin, si tu développez sur j2EE7, tu peux retirer spring de l'équation. EJB + CDI + JSF ça marche très bien pour des fonctionnalités similaires

[OButterlin]

De manière générale, tu peux soit utiliser Spring soit EJB3 pour la couche métier, les 2 solutions sont très abouties.
Pour la couche présentation, JSF + Primefaces qui est une bibliothèque de composants vraiment sympa.
Ensuite, il y a le débat possible sur le moyen d'injecter tes dépendances : JSF ou CDI...
Il semble que CDI soit largement favorisé par la communauté, mais j'y mettrais un bémol, il faut la version 2.2 de JSF, sinon, il va te manquer le scope VIEW, très intéressant dans bien des cas.

Autre point qui peut avoir son importance.
Avec les EJB, si tu optes pour des transactions JTA (défaut), il faut faire attention avec les propriétés en Lazy loading. En effet, dès que tu retourneras à la couche présentation (JSF), les entités seront détachées...
Dans la pratique, dans ce cas, il est préférable d'utiliser une couche DTO qui soit le reflet des données utilisées par la vue.

[Mishulyna]

J'irais moi plus loin, si tu développez sur j2EE7, tu peux retirer spring de l'équation. EJB + CDI + JSF ça marche très bien pour des fonctionnalités similaires

Même avec JEE 6 : jamais eu besoin de Spring moi.

Il semble que CDI soit largement favorisé par la communauté, mais j'y mettrais un bémol, il faut la version 2.2 de JSF, sinon, il va te manquer le scope VIEW, très intéressant dans bien des cas.

Vous le dites et je vous fais toujours confiance mais en fait je n'ai jamais utilisé @ViewScoped non plus... Avec FacesServlet qui gère tout (sauf les cas particuliers de redirection, où il faut écrire une Servlet assez laide), tout est géré et reste bien dans la session de l'utilisateur. Ça dépend bien sûr du but de l'application mais je ne voudrais pas qu'un objet puisse être modifié par un autre utilisateur entre deux vues de la même session.

Avec les EJB, si tu optes pour des transactions JTA (défaut), il faut faire attention avec les propriétés en Lazy loading.

Des collègues ont utilisé FetchType.LAZY, ils ne se sont jamais plaint.

Je vous prie de m'excuser (encore) de me mêler dans la discussion mais je voudrais apprendre un peu plus entre deux traductions,

[OButterlin]

Vous le dites et je vous fais toujours confiance mais en fait je n'ai jamais utilisé @ViewScoped non plus... Avec FacesServlet qui gère tout (sauf les cas particuliers de redirection, où il faut écrire une Servlet assez laide), tout est géré et reste bien dans la session de l'utilisateur. Ça dépend bien sûr du but de l'application mais je ne voudrais pas qu'un objet puisse être modifié par un autre utilisateur entre deux vues de la même session.

Le scope view est vraiment super intéressant avec les mises à jour assynchrones (ajax) ce qui est le cas le plus fréquent quand on utilise Primefaces. Tant qu'on reste sur une vue, les données restent, dès qu'on la quitte, elle sont purgées.
Le problème du scope session c'est que justement, 2 accès concurrents (par exemple 2 onglets du navigateur sur la même application) vont utiliser le même bean côté serveur et ça, c'est une source d'incohérence des données monstrueuse.

Des collègues ont utilisé FetchType.LAZY, ils ne se sont jamais plaint.

Ils utilisent les EJB, un conteneur Spring ou le conteneur de servlet ? Parce que ça change pas mal la problématique dans une application web...

J'utilise également le Lazy loading, ce n'est pas que je m'en plains, c'est juste qu'il faut faire attention parce que dès qu'on revient à la couche présentation, les entités sont détachées et il n'y a alors plus moyen d'accéder à des données lazy non initialisées.
On s'y fait, et en pratique, on fait une couche supplémentaire (DTO) qui est le reflet des données utilisées par la couche présentation.
Même si cette couche est un peu "chiante" à faire parce que souvent une copie du modèle entity, elle a le gros avantage d'abstraire l'application du modèle physique des données. On peut faire évoluer ce dernier plus facilement sans remettre en cause les applications existantes. Un autre avantage est que seules les données utilisées sont décritent.

[Mishulyna]

Ils utilisent les EJB, un conteneur Spring ou le conteneur de servlet ? Parce que ça change pas mal la problématique dans une application web...

Les EJB, Servlet et... GlassFish. Merci beaucoup pour vos explications très intéressantes !

[OButterlin]

J'oubliais un point, c'est quoi le problème de redirect avec FacesServlet ?
J'utilise la redirection systématiquement et n'ai aucun problème, du coup, je m'interroge

[Mishulyna]

Ah, c'est le cas particulier de l'utilisateur qui confirme son inscription sur le site en cliquant sur un lien reçu par mail : il faut valider les données et afficher une page en rapport avec le résultat de la validation + un lien pour rediriger l'utilisateur vers la page d'accueil. Et ça je n'ai pas réussi faire avec Faces.

[OButterlin]

Lorsqu'une action est appelée, elle peut renvoyer l'url en retour.
Pour une redirection, il suffit d'ajouter à la fin de ton url "faces-redirect=true"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
...
public String monAction()
{
   ...
   return "/maPage.xhtml?faces-redirect=true";
}

[Mishulyna]

En fait l'URL peut avoir un rapport avec les données du client, que je ne connais pas à l'avance. Mais peut-être je n'ai pas exploré toutes les possibilités.

[bruneltouopi]

Moi aussi j'ai décidé de migrer une application JEE vers Spring juste parce que je veux exécuter l'application dans un serveur léger donc tomcat.
J'avoue que la migration n'est pas aisé entre la gestion des transactions,le cycle de vie des objets par Spring et JSF.
Mais de mon expérience il vaux mieux déjà utiliser JSF 2.2 car il est aisé de manipuler les CDI qui peuvent même directement remplacé la DI spring ou EJB.

[footsteps]

Je m'immisce ici pour savourer le managed bean de jsf 2.
Ça c'est un sacré apport.. keep it simple.
Le reste c'est de la présentation..