Очень распространенное использование для pre_save - это убивание заголовков, например на книги, статьи или продукты. Это также одна из причин, по которой всегда лучше сохранять отдельный идентификатор для включения в URL-адреса и т. Д., А не полагаться исключительно на слагов, иначе вы либо не сможете изменить слагов, либо вам придется обойти тот факт, что постоянные страницы могут не иметь постоянные URL-адреса или должны поддерживать устаревшие URL-адреса / перенаправления.
post_save также может использоваться для запуска или постановки в очередь асинхронных событий; например, если вы синхронизируете своих пользователей с отдельной службой, может потребоваться отправить в API успешное изменение локального профиля пользователя, что не заставит пользователя ждать. Подобные вещи технически могут быть выполнены в другом месте, но включение этого сигнала означает, что вам не нужно беспокоиться о реализации или вызове этого где-либо еще.
pre_delete может использоваться в качестве проверки работоспособности, если у вас есть объекты, которые каким-то образом используются совместно и не будут восприняты более строгими on_delete аргументами . Например, если учитель должен иметь возможность удалять объект ученика только в том случае, если у этого объекта нет связанных записей посещаемости, это может быть одно место для принудительного применения этого.
post_delete, помимо таких вещей, как статистические пересчеты, может использоваться для предупреждения администраторов или модераторов о важном поведении пользователей. Если подписчик удаляет активный метод оплаты, в дополнение к деактивации этого метода оплаты в процессоре платежей, этот сигнал может вызвать отправку по электронной почте соответствующему продавцу о том, что ему грозит опасность оттока.
Когда вы получаете сигналы, я бы сказал, что вы слегка выходите из простой инфраструктуры CRUD, которая, вероятно, является наиболее распространенным вариантом использования Django. Поэтому трудно указать на «наиболее распространенные варианты использования», поскольку сигналы становятся более полезными, поскольку ваш проект становится более специализированным.
Они удобны, когда они вам нужны, но лично я использую их только несколько раз в год; это не то, что я бы предложил прыгнуть в качестве первого варианта. Многие или большинство вещей, которые вам нужно сделать с Django, можно сделать проще и удобнее, например, с помощью переопределенного метода save(...).