tag - Comment améliorer la productivité lors du développement d'applications Web basées sur Java EE



taglib java (10)

Depuis Jython 2.5, vous pouvez utiliser django pour satisfaire les exigences que vous avez répertoriées. Il est assez facile de générer des fichiers de guerre à partir de projets django et de les déployer sur des serveurs d'applications J2EE.

Je voudrais savoir comment vous abordez la productivité apparemment faible du développement d'applications Web basées sur Java EE par rapport à d'autres piles technologiques ( Seaside , Ruby on Rails , etc.).

Les contraintes sont:

  • L'application Web terminée doit pouvoir être déployée sur des conteneurs d'applications compatibles Java EE
  • Si possible, l'investissement antérieur dans une solution basée sur Java doit être préservé, c'est-à-dire que l'interopérabilité native avec les systèmes et les bibliothèques basés sur Java doit être possible
  • En raison de la structure de l'équipe, Java en tant que langage d'implémentation est préférable, bien que des langages moins exotiques basés sur JVM (c.-à-d. Groovy) puissent également être acceptés
  • Le système qui en résulte doit être architecturalement sain
  • Le système résultant doit être extensible et maintenable

Pour ne pas laisser cela se réduire à une discussion philosophique, je ne m'intéresse qu'aux suggestions basées sur l'expérience pratique. Des exemples possibles incluent des langages, des frameworks et des MDSD spécifiques à un domaine.

Si vous indiquez une classe abstraite de solutions (comme MDA / MDSD), veuillez fournir des détails sur la manière dont vous les avez mises en œuvre, ainsi que des informations sur les pièges courants et les meilleures pratiques.

Si vous n'êtes pas d'accord sur l'hypothèse que le développement d'applications Web basées sur Java EE implique une productivité inférieure, j'aimerais également connaître votre raisonnement.

EDIT: Comme il y a beaucoup moins de réponses que prévu, j'accepte aussi les comptes de tentatives avortées, en étendant la question à "Comment (pas) améliorer la productivité lors du développement d'applications Web basées sur Java EE?".


Answer #1

Eh bien, je ne suis pas vraiment un gars de Java, donc je ne peux pas en dire beaucoup, sauf pour ... JSF

Nous avons essayé de l'utiliser pendant un certain temps et c'était un désastre. Almots toutes les étapes de base ont dû être passées avec beaucoup de douleur, pas de documentation, pas d'exemples, pas de connaissance de la communauté. Nous avons ensuite utilisé un plugin pour Eclipse (Exadel Studio), nous avons examiné quelques autres frameworks JSF, ils étaient tous incompatibles et peu documentés. En fait, parmi tous ceux que nous avons essayés, seul le framework Sun (qui a oublié son nom, basé sur NetBeans) pourrait créer un nouveau projet JSF, même compilable, prêt à l'emploi. Le reste a nécessité de nombreux jours de configuration d’apache et d’autres choses, ce qui, pour une personne inexpérimentée, représente un véritable défi (même si je l’ai géré).

Notre équipe a passé quelques mois sur quelque chose qui a été fait plus tard dans quelques semaines avec ASP.NET. Les gens étaient tous deux inexpérimentés en JSF et ASP.NET.

Si l'écosystème JSF est toujours aussi mauvais qu'en 2007, je recommanderais de l'éviter complètement, la productivité est de toute façon hors de question. Peut-être rester avec JSP ou quelque chose qui est prouvé dans le temps et bien développé?


Answer #2

J'ai utilisé Jboss Seam ces deux dernières années et je trouve que c'est un moyen très productif de se développer en Java EE (en utilisant EJB3, Hibernate, Facelets). Je fais aussi un peu de codage PHP sur le côté et je peux honnêtement dire que je suis plus productif avec Seam (bien que cela soit probablement aussi une indication de mes compétences en PHP.)

Pour moi, deux points forts seraient:

  • Déploiement à chaud du code (indispensable)
  • SEC avec Facelets
  • Configuration basée sur les annotations
  • Composants étendus (en particulier ajax4jsf)
  • Prise en charge IDE des outils Jboss

Il existe des outils dans l'EDI et à partir de la ligne de commande pour créer du code squelette de la même manière que RoR.


Answer #3

J'irais avec le framework Lift écrit en Scala. Vous constaterez une amélioration de la productivité en passant simplement à Scala . Scala est également très stable et il est extrêmement facile d'appeler du code Java à partir de votre code Scala. Non seulement cela, mais il est assez similaire à Java mais avec quelques fonctionnalités supplémentaires. Pour certains exemples, vous devez vous référer à 5 choses qu'un développeur Java doit savoir sur Scala. Twitter va transférer une partie de son code à Scala.

Vous ne serez jamais "bloqué" sur un morceau de code car vous pouvez simplement penser à la façon de le faire en Java et écrire un code similaire. Des fonctions et des acteurs de premier ordre vous donneront un gain de productivité encore plus grand et sont tous deux à Scala. Scala est bien sûr typé statiquement et a des performances similaires à Java.

Je citerai l'auteur du framework Lift pour une description de celui-ci:

Soulever les emprunts du meilleur des cadres existants, en fournissant

  • Les sessions très granulaires de Seaside et les Rails de sécurité rapides comme un flash-to-bang
  • Django "plus que CRUD est inclus"
  • Le style de gabarit convivial de Wicket (voir Lift View
    Premier)

Et comme les applications Lift sont écrites en Scala, un nouveau langage JVM élégant, vous pouvez toujours utiliser vos bibliothèques Java préférées et les déployer sur votre conteneur Servlet préféré. Utilisez le code que vous avez déjà écrit et déployez sur le conteneur que vous avez déjà configuré!


Answer #4

Je vais certainement aller avec Spring avec Hibernate pour les choses liées à la persistance.

Pourquoi le printemps?

L'avantage d'utiliser Spring plutôt qu'un autre cadre est que la philosophie de Springs doit être " non invasive ". Habituellement, lorsque vous utilisez un framework, vous commencerez probablement à dépendre de ce framework, ce qui peut être un problème si l'application est considérée comme exécutée plus longtemps, alors que vous devez également faire de la maintenance, etc. appelé "Inversion de Contrôle" (IoC) . Fondamentalement, votre code n'appelle pas (il peut mais il ne doit pas) appeler Spring, mais Spring vous appellera (principe d'Hollywood: "ne m'appelez pas, je vous appellerai"). Ainsi, par exemple, vous pouvez utiliser des objets POJO normaux (Plain Old Java Objects) et vous n'avez pas à hériter des classes / interfaces liées à la structure. Un autre gros problème (sinon le plus important) en génie logiciel est celui des dépendances. Vous devrez vous battre pour les réduire autant que possible, car ils vous rendront la vie plus difficile (en particulier lors de la maintenance ultérieure). Spring réduit considérablement les dépendances entre vos composants en gérant l'instanciation des composants via les fichiers de configuration et le modèle d' injection de dépendance . Je ne voudrais pas continuer, la meilleure chose est que vous commencez à lire des tutoriels sur le site officiel de Spring . Au début, il faudra peut-être du temps pour comprendre, mais une fois que vous l'aurez compris, vous gagnerez beaucoup d'avantages.


Answer #5

Je voulais juste lancer une autre idée ... vous pouvez réellement utiliser JRuby et Rails (similaire au précédent commentaire sur Django et Jython).

Si vous utilisez JRuby avec Rails et JRuby Rack (et peut-être d'autres utilitaires ... je n'étais pas le premier à intégrer cette intégration), vous pouvez déployer des ajouts à JRuby Rails dans une application Web Java existante. Nous avons une application JSP héritée déployée avec Tomcat et nous commençons maintenant à ajouter de nouvelles pages à l'aide de Rails avec cette configuration (en plus d'étendre le côté JSP si nécessaire). Jusqu'à présent, le succès a été au rendez-vous, bien que nous n'ayons aucune des grandes pages à fort trafic implémentées dans Rails, donc je ne sais pas à quel point cela va évoluer.

Nous avons un accès complet à la session et avons même mis en place des mécanismes pour invoquer les JSP à partir des pages Rails (telles que les en-têtes et les pieds de page inclus). Il faut un certain effort et des essais et des erreurs pour intégrer complètement le 2, mais si Rails et JRuby sont une option, je le recommande fortement (en tant que fan personnel de Ruby).

Un collègue a touché à JBoss Seam, qui est un framework de Gavin King (le gars qui nous a apporté Hibernate), qui devait émuler Rails. Ayant vu les deux, je pense que Rails est beaucoup plus facile à développer.


Answer #6

Quelques règles de base:

  1. Démarrez le serveur d’applications - un gain énorme en termes de délais et de qualité. Conservez un conteneur Web si vous devez le faire, mais configurez tout dans Spring et / ou Hibernate pour que le fichier web.xml soit minimal.

  2. Tout tester, ce que vous pouvez faire maintenant à l’étape 1 (pas de XML au moment du déploiement ni de génération de code nécessaire: tout est déjà configuré dans le développement).

  3. Utilisez Wicket pour implémenter votre niveau Web - personne n'a plus besoin de JSP; Le guichet est 10 fois plus productif et facile à tester (voir étape 2).

  4. Utiliser les méthodologies de développement SCRUM et agile

Le résultat est que la productivité de Java est aussi élevée que le permettent les 4GL - chez Atomikos, nous avons eu plusieurs projets de migration comme celui-ci. Comme nous avons migré des plates-formes 4GL vers Java / Java EE, nous avons pu comparer les estimations dans les deux.

Voir aussi cet article de blog:

HTH

Gars


Answer #7

Un point important lors de la discussion sur la productivité Java EE: vous devez utiliser Java EE 5 et EJB3.x car ils offrent un nouveau niveau de productivité (et de fonctionnalités) par rapport aux versions précédentes.

Rester dans les spécifications Java EE standard est absolument important. Par exemple, utiliser Hibernate au lieu de JPA n'est pas bénéfique pour la productivité. Il n'y a pas de limite à se rabattre sur les fonctionnalités Hibernate lors de l'utilisation de JPA, mais en utilisant Hibernate au lieu de JPA, vous êtes bloqué dans un fournisseur de persistance unique sans aucune solution économique. L'idée derrière l'utilisation des standards est la même: flexibilité conceptuelle (en branchant différentes implémentations) avec une extensibilité disponible (en utilisant des extensions propriétaires si cela est absolument nécessaire). Java EE 5 et EJB3 sont des pas importants dans cette direction. Bien sûr, vous voulez minimiser les fonctionnalités propriétaires, mais si certaines semblent absolument nécessaires, c'est un bon signe qu'elles feront partie des spécifications dans la prochaine version ...

Les principaux obstacles à la productivité Java EE sont liés à l’entreprise (offre bien plus que nécessaire pour la majorité des projets) et à son héritage (compatibilité descendante). Il y a aussi beaucoup à faire dans le domaine de la présentation avec JSF et la gestion de l'état - surveillez la JSR-299 pour y remédier, entre autres améliorations.


Answer #8

Grails est un framework Webapp Java basé sur Ruby on Rails, avec des principes similaires (DRY, CoC) et des gains de productivité, mais basé sur des frameworks Java existants (Spring, Hibernate, etc.).

Je travaille sur un projet exploratoire utilisant Grails depuis quelques semaines (aucune expérience antérieure sur Grails ou Groovy) et je suis très impressionné. Il y a quelques difficultés: ce n'est pas aussi mature que RoR, mais vous pouvez obtenir des résultats rapidement et le sentiment que le cadre ne vous gêne pas.

Peut-être est-ce mieux illustré par cet exemple concret: je voulais éditer un tableau 2D d'objets de domaine dans une grille sur une seule page Web et j'ai trouvé que le mappage automatique des données HTML résultantes sur les objets du domaine (fourni par Spring MVC ) avait un bug qui provoquait le mappage de certaines données sur les mauvais objets. J'ai regardé le web pendant une heure, mais apparemment, personne n'avait rencontré ou résolu le problème. Finalement, j'ai décidé de renoncer au mappage automatique et de le faire "manuellement" - puis j'ai constaté qu'il ne me fallait pas plus de 10 lignes de code ...


Answer #9

Javarebel peut considérablement réduire le temps passé lors du développement Web en utilisant Java.

Permettez-moi de citer ici le site officiel:

JavaRebel est un plug-in JVM (-javaagent) qui vous permet de voir immédiatement les modifications apportées à votre code, sans avoir à redéployer une application ou à effectuer un redémarrage du conteneur. Si vous en avez assez de regarder les journaux passer et que vous voulez voir vos modifications pour que vous puissiez continuer - JavaRebel est votre nouveau meilleur ami.





web-applications