Discussion :

[Romz82]

Bonjour,

je me pose quelques questions sur l'utilisation d'EJB en grand nombre dans une application:
je travaille sur un projet de taille moyenne (un peu plus de 100.000 lignes) qui utilise 120 EJB.
En fait, quasiment toutes les classes métier de l'application sont des EJB locaux, et c'est seulement la propriété d'auto-injection des EJB qui est utilisée.

Je me demande si c'est une bonne pratique de déployer un tel nombre d'EJB, et si la seule utilisation de l'injection justifie de faire de chaque classe métier un EJB?
Est-ce que ça ne risque pas de poser des problèmes de performance une fois l'application en production?

Est-ce qu'il ne serait pas préférable d'utiliser d'autres frameworks d'injection?

[fr1man]

Vous n'utilisez pas les aspects transactionnels, voire sécuritaires ?

[youx]

Vous n'utilisez pas les aspects transactionnels, voire sécuritaires ?

comme vu dans quelques projets et leurs justifications: c'est beaucoup plus simple à instancier, il n'y a pas à faire de "new" à faire.

[fr1man]

Ca me parait un peu léger comme explication.
Dans ce cas, depuis java ee 6, on peut faire de l'injection de bean sans pour autant qu'ils soient des EJB.

[Romz82]

Bonjour fr1man,

oui ça me semblait aussi un peu léger d'utiliser les EJB juste pour éviter le new! Et c'est un peu ce qui est fait sur ce projet...

Au sujet des transactions, certaines classes utilisent les transactions mais pas la plupart. La sécurité est gérée uniquement à la connexion, je ne crois pas qu'on utilise les fonctionnalités de sécurité des EJB (à vérifier, là je suis en vacances et je n'ai pas le code sous la main ^^)

Je ne savais pas qu'on pouvait faire de l'injection de bean sans les EJB, tu aurais des liens sur le sujet?
Une recherche Google sur java ee 6 bean injection me renvoie justement vers les EJB...

[fxrobin]

Si tu fais des EJB 3, par défaut ils sont transactionnels.
Par défaut aussi leur cycle de vie est géré par le conteneur (donc, pool d'EJB) ce qui est un vrai gain de performance puisque cela évite les "new".

Pour éviter "autant" d'EJB (si ça te gène, car perso, je ne trouve pas cela gênant) tu peux toujours les inclure dans quelques "Facades" qui frontalise justement les autres.

[fr1man]

Regarde du coté de CDI (contexts and dependency injection).
http://docs.oracle.com/javaee/6/tutorial/doc/gjbnr.html

Coté EJB, j'oubliais, entre autre, l'aspect accès distant via les interfaces remote qui peut etre intéressant.
Donc avant de tout jeter, il vaudrait mieux etre certain de la raison exacte pour laquelle ils ont été mis en place, car j'ai du mal à croire que la personne qui a choisi cela, a simplement vu le coté instanciation facile.

[Romz82]

Oui fxrobin, ce sont bien des EJB3.

Je vois bien l'idée de transaction pour l'accès en base, par ex nos DAO sont des EJB transactionnels, mais pour les services je ne vois pas trop ce que ça signifie?

C'est à dire que si j'ai une classe EJB de service et qu'une erreur s'y produit, eh bien... quoi donc? S'il y a eu un appel de DAO qui s'est bien déroulé avant l'erreur, la base retournerait à son état initial?