Je schématise beaucoup en effet (j'étais pressé). Mais les tests sont très intéressants néanmoins. C'est à ma connaissance les seuls tests comparant les différents patterns J2EE, ainsi que RMI et Jeremie, le tout pour Jonas, et je voulais surtout fournir le lien en pâture à la faune locale ;-)
Par ailleurs, JNDI, Web services, JDBC, tout ça n'est pas le propre de J2EE. A peu près tous les serveurs d'applications Java utilisent ces couches (ya pas vraiment le choix, sauf peut-être pour la couche LDAP, qui est grave pourrie dans JNDI, alors que Novell en a une belle qu'ils ont filé à OpenLDAP), et même si tu fais du développement servlet-only dans Tomcat, tu vas les utiliser (d'ailleurs, c'est ce que tu fais, non ? ;-)). Ce qui fait le coeur de J2EE c'est bel et bien les EJB (mais je suis d'accord avec toi que ce n'est pas le seul élément).
De plus, les EJB et J2EE ont un autre avantage que je n'ai pas cité, c'est que leur aspect modulaire fait qu'en réalité, pour les programmer, on utilise en général largement de la génération de code (à vrai dire, on a pas vraiment le choix, cf. les indications de complexité du code dans le test).
Enfin, je pense que tu devrais vraiment regarder du coté d'Enhydra pour ton projet. En gros Enhydra offre également un support de type MVC, mais en bien propre: il y a DODS, qui fait de l'encapsulation objet JDBC pour les accès base (par génération de code). Tu utilises ensuite ces objets de données (DO) pour implémenter ta couche business, et pour finir tu construis des objets de présentation (PO) qui utilisent les objets business, ainsi que des objets DOM pour générer les pages web. Ces objets DOM sont générés par XMLC, qui "compile" des pages HTML (ou XML, ou WML, ou XHTML) de template en DOM Java, en fournissant via de la génération de code les raccourcis idoine pour y accéder facilement. Le tout est lancé dans ce qu'ils appelent une SuperServlet.
En conclusion, tout dépend de la taille du projet et de tes besoins. Il va de soi que plus le projet est gros, plus la modularité est un atout. De même, si le projet doit être inséré dans un environnement déjà assez complexe et J2EE et qu'on veut de l'interopérabilité à mort, ben il faut faire du J2EE. Par contre sur un petit ou moyen projet mieux vaut privilégier les perfs par rapport à ce qu'apporterait J2EE, et si on veut de l'interopérabilité, il suffit de développer un backend XML.
[^] # Re: Avantages ?
Posté par anonyme512 . En réponse à la dépêche JOnAS 3.1 est sortie. Évalué à 2.
Par ailleurs, JNDI, Web services, JDBC, tout ça n'est pas le propre de J2EE. A peu près tous les serveurs d'applications Java utilisent ces couches (ya pas vraiment le choix, sauf peut-être pour la couche LDAP, qui est grave pourrie dans JNDI, alors que Novell en a une belle qu'ils ont filé à OpenLDAP), et même si tu fais du développement servlet-only dans Tomcat, tu vas les utiliser (d'ailleurs, c'est ce que tu fais, non ? ;-)). Ce qui fait le coeur de J2EE c'est bel et bien les EJB (mais je suis d'accord avec toi que ce n'est pas le seul élément).
De plus, les EJB et J2EE ont un autre avantage que je n'ai pas cité, c'est que leur aspect modulaire fait qu'en réalité, pour les programmer, on utilise en général largement de la génération de code (à vrai dire, on a pas vraiment le choix, cf. les indications de complexité du code dans le test).
Enfin, je pense que tu devrais vraiment regarder du coté d'Enhydra pour ton projet. En gros Enhydra offre également un support de type MVC, mais en bien propre: il y a DODS, qui fait de l'encapsulation objet JDBC pour les accès base (par génération de code). Tu utilises ensuite ces objets de données (DO) pour implémenter ta couche business, et pour finir tu construis des objets de présentation (PO) qui utilisent les objets business, ainsi que des objets DOM pour générer les pages web. Ces objets DOM sont générés par XMLC, qui "compile" des pages HTML (ou XML, ou WML, ou XHTML) de template en DOM Java, en fournissant via de la génération de code les raccourcis idoine pour y accéder facilement. Le tout est lancé dans ce qu'ils appelent une SuperServlet.
En conclusion, tout dépend de la taille du projet et de tes besoins. Il va de soi que plus le projet est gros, plus la modularité est un atout. De même, si le projet doit être inséré dans un environnement déjà assez complexe et J2EE et qu'on veut de l'interopérabilité à mort, ben il faut faire du J2EE. Par contre sur un petit ou moyen projet mieux vaut privilégier les perfs par rapport à ce qu'apporterait J2EE, et si on veut de l'interopérabilité, il suffit de développer un backend XML.