Discussion :

[A&N_L]

Bonjour à tous,

Je suis actuellement à rédiger les spécifications d'une nouvelle application.

Il s'agit plus précisément d'une grosse évolution d'une application d'administration, de back office, suite à la refonte complète du métier de l'application à administrer.

J'en suis donc à me poser un certain nombre (voir un nombre certain...) de questions architecturo-logicio-existentielles (si si, il existe ce mot !).

Cette application devra opérer tous les opérations de CRUD possibles propres à une application d'administration.

Au final, une application web de gestion pleine de formulaires...

Rentrons dans le vif du sujet...

Le métier de l'application à administrer sur lequel s'appuie(ra) mon application de gestion a été développé en EJB 3.0.
Pour l'instant, hors de question d'en changer (touche pas à ça petit con !)...

Quant à la partie présentation des données, l'existant a lui été développé en JSP/Servlet JEE 5 ; à cela, rajoutez un peu d'AJAX (DWR et DataTables).

Comme il m'est plus ou moins donné carte blanche (les fous !!) quant aux choix technologiques à mettre en oeuvre, je me demande s'il ne serait pas opportun de passer à autre chose...?

Changer pour quoi...? Pour rendre l'application plus maintenable, plus évolutive, plus performante...? Pour le plaisir de changer...? Pour voir du pays, se former...?

Tout le métier est donc en EJB 3.0 : session stateless & entity, le tout déployé sur GlassFish v3.

Mes questions "changement" :

- Que pensez-vous de passer à JSF 2.0 ? Si oui, ne vais-je pas rencontrer des problèmes de "compatibilité" entre JSF 2.0 (JEE 6) et mes EJB 3.0 (JEE 5) ?
- Passer au duo JSP/Servlet JEE6... (même si, de prime abord, je n'en vois pas trop l'intérêt...?) ?
- Tout autre chose...?
- Devrais-je au contraire rester avec le duo JSP/Servlet JEE5 ?

Merci par avance pour vos retours d'expérience en la matière !

[OButterlin]

Je ne sais pas trop où on en est d'un point de vue stabilité avec JSF 2.0...

S'il y a un problème, tu peux te retourner vers JSF 1.2 + Facelets + Seam + RichFaces.

Pour les EJB 3.0, bon choix... le passage à 3.1 apporte certains petit plus (comme le tri des listes sous-jacentes dans un entity).
La migration de 3.0 -> 3.1 ne devrait pas être gênante.

Après, il y a tellement de façons différentes de faire pour la même application, on peut vouloir limiter les risques et rester sur des framework connus... à toi de voir...

[A&N_L]

Salut OButterlin,

Merci pour ton éclairage.

S'il y a un problème, tu peux te retourner vers JSF 1.2 + Facelets + Seam + RichFaces.

JSF 1.2 et RichFaces, ceux-là, je les ai.
Facelets + Seam, ceux-là par contre, je ne les ai pas...
Qu'apporteraient-ils/quels seraient donc leurs rôles au sein de mon architecture/application ?
Pour rappel, il ne s'agit que d'une "simple" application de gestion, aussi fournie soit-elle...
Ne serait-ce pas sortir le bazooka pour flinguer une simple mouche...?

Pour les EJB 3.0, bon choix... le passage à 3.1 apporte certains petit plus (comme le tri des listes sous-jacentes dans un entity).
La migration de 3.0 -> 3.1 ne devrait pas être gênante.

Même si je partage ton avis (je pense notamment aux EJB 3.1 Lite et du coup au web profil car nous n'utilisons que le métier des stateless et des entities, rien d'autre), nous sommes une toute petite équipe actuellement, je ne suis donc pas certain que mes collègues soient enthousiastes à cette idée-là, aussi noble soit-elle, la charrette débordant depuis déjà bien longtemps !

Après, il y a tellement de façons différentes de faire pour la même application, on peut vouloir limiter les risques et rester sur des framework connus... à toi de voir...

Je suis d'accord avec toi.
Ainsi, la première remarque qui m'est faite quand je fais part autour de moi de l'éventualité de "changer", c'est : "Mais pourquoi tu veux changer...?".
Le couple JSP/Servlet ayant effectivement fait ses preuves...

Mais moi, justement, je changerais bien !

[OButterlin]

Globalement, JSF + Facelets + Seam = JSF 2.0

Pour la persistance et la couche métier, il faut bien reconnaître que les ORM apportent un plus dans la modélisation.
On peut effectivement faire autrement, plus performant, en utilisant JDBC.
A priori, la performance optimale sera atteinte avec des procédures stockées. On pourra cependant avoir des problèmes de migration d'une base vers une autre si le besoin devait exister...
Bref, je préfère pour ma part perdre une milliseconde et avoir un modèle objet, mais ça reste un débat philosophique...
D'ailleurs, par endroits, j'utilise des accès natifs quand il faut optimiser certaines requêtes de recherche.
J'irais même jusqu'à dire que le modèle métier devrait être géré par un ORM et les requêtes de recherche par un accès natif. Pour ça, JPA propose des choses intéressantes.

Dernier point : pourquoi changer ?
Parce qu'à un moment, on ne trouve plus personne pour maintenir
Plus sérieusement, de plus en plus d'ajax entre dans les applications web, on peut le faire avec du javascript de base (surtout avec jQuery) mais avoir un framework de présentation comme RichFaces qui englobe le tout permet de développer plus vite...

[manblaizo]

Globalement, JSF + Facelets + Seam = JSF 2.0

Hmmm, pas tout à fait quand même, Seam représente bien plus qu'un simple complément à JSF 1.2... En gros, Seam 2 a pour ambition de faciliter l'intégration entre EJB3.0 et JSF1.2, et au passage il apporte aussi des améliorations et autres solutions aux manquements de JSF1.2

Mais la plupart des gros problèmes qu'il y avait dans JSF1.2 ont été corrigés dans JSF 2.0, en s'inspirant d'ailleurs des workarounds qu'apportaient Seam, RichFaces, ICEFaces, etc. Et il y a bien plus encore dans JSF2.0

Tous ces correctifs ayant été apportés à JSF, Seam3 se concentre dorénavant sur l'intégration et l'extension des services Java EE en se basant totalement sur la jsr-299 (CDI) dont le spec lead n'est autre que Gavin King, le créateur de Hibernate et Seam.

Bon, tout ça pour dire qu'à mon avis JSF 2.0 est déjà stable, parce que ça fait quand même au moins deux ans que c'est sorti, bien avant la sortie officielle de Java EE6. C'est vrai qu'il y a encore des améliorations à faire, surtout au niveau de l'interopérabilité entre les différentes librairies de composants (RichFaces, PrimeFaces, ICEFaces...), mais les équipes de développement de ces dernières se coordonnent déjà en ce moment, et apparemment ça devrait être plus simple de faire coexister des composants de différentes librairies que par le passé. La JSR pour JSF 2.1 a déjà été ouverte et on peut déjà faire des propositions pour des améliorations...

En tout cas, à partir du moment où tu déploies déjà sur GlassFish3, donc un serveur d'applications compatible Java EE6, il serait dommage de pas profiter de toutes ces nouveautés qui facilitent le développement (CDI, JSF2.0, EJB3.1, JPA2.0, Bean Validation...), d'autant plus qu'elles sont déjà là par défaut.

Pour tes EJB3.0, je ne vois pas pourquoi tu ne continuerais pas à les utiliser même dans GlassFish3, il n'y a rien de nouveau de côté là, l'API n'a pas changé pour qu'on ait des problèmes d'incompatibilité. Par contre, tu pourrais profiter du déploiement de tes EJB dans un simple WAR, des Singletons, des méthodes asynchrones, de global jndi names, d'un service Timer amélioré...

Il y a plein de docs sur Weld (CDI), JSF2.0, JPA2.0, EJB3.1, pour explorer et ensuite prendre ta décision.

Bon courage.

[Jacobian]

-JSF:au niveaux des performances je déconseille l'utilisation de JSF tu va payer de 5-10 % en perf par contre il est bien en terme de maintenabilité de la couche présentation.

-Struts ou JSp/servelet : au niveaux perfr il sont bien mais tu vas payer aux niveaux maintenance