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