Spring Boot – Écoutez vos entités sans faire crier votre code : SQL vs MongoDB
Introduction
Saviez-vous que vous pouvez déclencher des actions automatiquement dans Spring Boot à chaque fois qu’une entité est créée, modifiée ou supprimée ?
Grâce aux EntityListeners (JPA) ou aux EventListeners MongoDB, Spring permet de réagir à la vie de vos entités, sans avoir à le coder dans vos services.
Mais cette magie peut rapidement devenir dangereuse si mal utilisée : logique invisible, difficultés de test, couplage fort, etc.
Cet article explore :
- la différence entre les deux types de listeners
- les méthodes à override
- les avantages réels, mais surtout les inconvénients
- comment les utiliser sans compromettre la lisibilité et la maintenabilité (Clean Code)
1. Pourquoi vouloir « écouter » les entités ?
Cas d’usage typiques :
- Mettre à jour automatiquement des champs
- Logger les opérations
- Nettoyer les champs (email en lowercase, suppression d’espaces)
- Déclencher des événements métiers (notifications, alertes…)
Centraliser du comportement transversal, sans l’éparpiller dans tous vos services.
2. EntityListeners (JPA – SQL)
2.1 Activation
L’activation se fait avec l’annotation @EntityListeners
2.2 Exemple d’implémentation
Toutes les méthodes prennent un seul paramètre : l’entité concernée (de type
Objectou typé comme sur l’exemple si vous le souhaitez).
3. MongoDB : AbstractMongoEventListener (Spring Data Mongo)
3.1 Activation
3.2 Exemple d’implémentation
Les méthodes reçoivent un unique événement typé, ex.
BeforeSaveEvent<User>.
Utilisezevent.getSource()pour l’objet Java,event.getDocument()pour le BSON, etevent.getCollectionName()si besoin.
4. Comparaison SQL vs Mongo
| Critère | EntityListener (JPA) | Mongo Event Listener |
|---|---|---|
| Standard | JPA / Hibernate (Java EE) | Spécifique Spring Data Mongo |
| Accès aux données | Objet Java uniquement | Objet Java + Document BSON |
| Type de méthodes | Annotations (@PrePersist,…) | Méthodes à override |
| Contexte (user/session) | Difficile | Difficile |
| Complexité des scénarios | Moyenne | Plus riche grâce aux événements typés |
| Lisibilité / Maintenance | Risque élevé si abusé | Risque élevé si abusé |
5. Clean Code : ce qu’il faut absolument éviter
Mauvaises pratiques
- Mettre de la logique métier lourde (ex : appel à une API, envoi de mail, billing…)
- Modifier d’autres entités ou collections dans le listener sans contrôle transactionnel
- Utiliser des listeners comme une “solution magique” pour éviter les services
Bonnes pratiques
- Garder les listeners simples et prévisibles
- Ne faire que des tâches techniques (audit, nettoyage, timestamps…)
- Si besoin de logique métier : publier un événement Spring (
ApplicationEventPublisher) et le traiter ailleurs - Bien documenter chaque listener
- Tester isolément chaque listener
6. Tester les Listeners
- Tester les listeners de façon unitaire (Mockito sur les événements)
- Attention : certains listeners s’exécutent aussi dans les tests d’intégration
- Prévoir une désactivation conditionnelle (via
@Profile("!test"), par exemple)
7. Avantages / Inconvénients
Avantages
- Centralise des comportements communs
- Évite de dupliquer des blocs de code (ex : timestamps)
- Simplifie les entités en surface
Inconvénients
- Logique invisible → difficile à comprendre sans lire tout le projet
- Pas transactionnel si on modifie plusieurs objets
- Trop de magie nuit à la lisibilité
- Testabilité réduite si mal structuré
Conclusion
Les EntityListeners (JPA) et AbstractMongoEventListener sont des outils puissants… mais pas toujours adaptés.
Dans une démarche Clean Code, il faut :
- éviter l’abus de logique métier dans ces hooks
- préférer des usages techniques simples
- bien tester et documenter
Astuce : si un développeur ne comprend pas pourquoi un champ est modifié sans appel explicite → c’est que le listener est mal utilisé.