Contrairement à ce qu'on pourrait croire, un Enterprise JavaBean n'est pas juste une classe avec des annotations. C'est un composant géré par le conteneur qui apporte des services métier cruciaux sans polluer votre code.
Le conteneur Jakarta EE s'occupe de tout : gestion des transactions, sécurité, injection de dépendances, et même la mise en pool des instances. Vous écrivez la logique métier, lui gère l'infrastructure.
Regardez ce code : aucune gestion explicite de transaction, pas de try/catch pour les ressources, pas de configuration manuelle. Le conteneur fait le travail lourd.
Les EJB restent pertinents dans les architectures d'entreprise où la robustesse et la simplicité de développement priment sur la performance brute. Parfois, déléguer la complexité au conteneur est le choix le plus intelligent.
Qui fait encore les EJB en 2025 ? 🤭
J'ignore ce qu'est devenue la spec. sur les EJB, mais c'était trop complexe. C'est d'ailleurs la contre-motivation même de Spring : se passer de ce truc complexe.
Juste pour savoir, tu déploies tes EJB sur quel serveur d'application ?