Struts / Struts 2 / JSF 1/2 et DAO: pour une application web que choisir ?

Bonjour, je me pose cette question aujourd'hui parce que il y a l'embarras du choix.
Aujourd'hui, pour une application Web entreprise en client léger et en java j2ee, quel choix est naturel a faire et pourquoi.
J'ai besoin de réfléchir à ce choix pour migrer une application de 200 utilsateurs, en ligne, avec des calcul et traitements complexes, des accès bases de données.
Je vais avoir besoin de bien m'orienter, vers une direction sure, éprouvée, souple, scalable, réutilisable et bien solide.
J'ouvre le débat.

De même pour la couche DAO, que choisir également ? un framework spécifique?

Merci à tous de venir y participer. Bienvenue à vous.

:ptdr::lol:

200 utilisateurs, ça reste assez peu, donc, pour ma part, je choisirais JSF2 avec Primefaces pour la partie IHM si l'application est typée RIA.
JSF est un standard et Primefaces est une bibliothèque de composants vraiment sympa et complète.

Pour l'accès à la base de données, tout dépend du volume de la base et des relations entre tables à gérer.
Tu peux t'orienter vers un ORM (Hibernate, EclipseLink), soit directement soit au travers de JPA, sous forme de beans simple ou d'EJB.

Maintenant, c'est difficile de répondre de manière catégorique dans la mesure où tu ne dis pas grand chose des contraintes de l'application.
Si elle doit être réactive, haute disponibilité, multi-langues, etc...

Citation:

---

m'orienter, vers une direction sure, éprouvée, souple, scalable, réutilisable et bien solide

---

On peut faire ça avec pas mal de technologies, généralement, c'est plus celui qui développe qui est en cause que la techno proprement dite.
Avec struts1, on peut faire des applications robustes, réutilisables, souples et éprouvées... mais bon, la techno n'est plus maintenue et les compétences risquent d'être plus rares.
Struts2... je ne connais pas donc je ne peux rien en dire
Il y a aussi les frameworks javascript comme AngularJS, ExtJS qui ont une bonne cote mais personnellement, j'estime que la compatibilité avec les navigateurs n'étant pas assurée (on a le cas), c'est une mauvaise solution avant que javascript lui-même ne soit unifié.

Pour ce qui est de la couche métier, on a en gros 3 choix :
- EJB3
- Spring
- Objets java simples

Certains diront que Spring est génial, super, moins contraignant qu'EJB etc, mais en fait, à l'heure actuelle, ça ne fait pas grand chose que le standard JEE ne fasse... Personnellement, j'utilise EJB3 au boulot et j'apprécie vraiment...
A titre privé (auto-entrepreneur), j'utilise des DAO sous forme d'objet simple et Hibernate pour l'ORM ou JDBC directement.
Le seul avantage ici, c'est qu'on peut se passer d'un serveur JEE complet, un simple Tomcat fait l'affaire...

Voilà, ce n'est que mon avis ;)

Salut,
C'est un peu large comme demande je trouve 8-). En effet aujourd'hui il y a nombre de solutions qui sont pérennes, full spring, coupler struts1/2 avec spring, pour la partie DAO hibernate ou JPA mais tu as aussi JAVA EE 6-CDI. Je pense qu'il faut que tu nous délimites un peu plus ton projet, par exemple, les contraintes de temps, des impératifs technique, l'existant, la réutilisation de code si ton appli est déjà en Java, tes connaissances ...

:D :D

Si tu veux quelque chose de scalable, il serait judicieux d'oublier les solutions Struts/JSF qui reposent assez naturellement sur la session.
La session est un concept difficilement scalable.

Côté serveur pour le traitement des requêtes tu as Struts1 (à oublier, pas le plus productif et plus maintenu), Struts2 (plus vraiment la côté du côté des développeurs), JSF (le standard JEE), Spring MVC (le standard de Grails), Spring REST (couche au-dessus de Spring MVC pour offrir un développement "naturel" de services REST), ...

Côté serveur pour la génération de vues (pas le domaine que je connais le mieux) : Facelets (JSF) + framework composants [PrimeFaces (surement le plus plébiscité), RichFaces (utilisateur/correcteur je recommande pas), ICEfaces (assez discret)]

côté client : ember, AngularJS (j'utilise avec plaisir, mon seul reproche un binding systématique très couteux en ressource mémoire/CPU. Les prochaines versions devraient permettre d'être flexible), Backbone.js, ...


Frameworks FullStack : Grails (pas essayé mais assez tendance), Play! Framework (très tendance, assez répandu chez les PaaS), Lift (connais pas), ...

Plateformes : J2EE, Vert.x (plateforme pour la programmation asynchrone, meilleur scalabilité en mono-machine), GWT/Vaadin (s'essoufle un peu, certains ont rencontré des problèmes de montée en charge), ...


Comme tu peux le voir rien qu'un petit résumé et c'est déjà la foire d'empoigne.
En général le choix s'effectue sur la base des connaissances actuelles (et éventuellement le goût/l'envie d'essayer une techno/un principe en particulier). Pour la plupart des technologies, il faudra s'investir à fond dans celle-ci.
Ainsi pour JSF, il faudra partir sur les Facelets avec un framework de composant et très certainement une stack J2EE. Pour Grails, il faudra adopté Spring (Beans, Context, MVC), Gant et Groovy pour en tirer pleinement partie.
Pour les frameworks client, JavaScript sera un passage obligé (ou presque, voir Dart, TypeScript, CoffeeScript, Ceylon, etc.)
Pour Play! ce sera SBT et Scala (et surement MongoDB).
Pour Vert.x avec l'arrivée de Java8 les langages alternatifs (Groovy, Scala, Ceylon, JavaScript, Clojure, etc.) ne seront peut-être pas une nécessité mais offrirons surement une meilleur productivité.

Donc mon conseil, fait le point sur les compétences à ta disposition, les envies d'apprendre de nouvelles choses et le temps dispos pour apprendre de nouvelles choses (avec ET sans envies) + le temps pour essuyer les plâtres.

Merci tout d'abord pour vos explications. Il faut que je fasse le tri dans tout ce qui a été dit, afin de partir dans la bonne direction.
Je n'ai pas encore assez analysé pour l'instant toutes les contraintes. Mais , il semble que beaucoup
de voies sont possibles.
Merci donc de participer à cette phase de déffrichage, ou dégrossissement dans le domaine.

:P

Le débat n'est pas clos, mais il est clair que c'est très vaste, et qu'il faudra bien cibler mes besoins à différents niveaux.