Il existe de nombreuses façons de résoudre le problème que vous avez décrit :
- Logique d'application
- Logique spécifique à la vue -- Si le comportement est spécifique à une seule vue, placez les modifications dans la vue.
- Logique spécifique au modèle -- Si le comportement est spécifique à un seul modèle, alors remplacer la méthode save() pour le modèle.
- Logique du middleware -- Si le comportement concerne plusieurs modèles OU doit être intégré à une application existante, vous pouvez utiliser le signaux pré-sauvegarde/post-sauvegarde pour ajouter des comportements supplémentaires sans modifier l'application elle-même.
- Procédures stockées de base de données -- Normalement une possibilité, mais l'ORM de Django ne les utilise pas. Non transférable d'une base de données à l'autre.
- Déclencheurs de base de données -- Non portable d'une base de données à une autre (ou même d'une version d'une base de données à l'autre), mais vous permet de contrôler le comportement partagé entre plusieurs applications (éventuellement non-Django).
Personnellement, je préfère utiliser soit la substitution de la méthode save(), soit l'utilisation d'un signal Django. L'utilisation d'une logique spécifique à la vue peut vous empêcher d'accéder à de grandes applications avec plusieurs vues du ou des mêmes modèles.
