Что такое Django signals?

Question

Accepted Answer

**Signals** — это реализация Django паттерна Observer — они позволяют определённым отправителям уведомлять множество получателей когда происходят специфичные **события** (например, сохранение или удаление модели). Они обеспечивают **слабо связанный** код: одна часть приложения реагирует на события в другой без прямой зависимости.

## Распространённые встроенные signals

```text
pre_save / post_save      → before / after a model instance is saved
pre_delete / post_delete  → before / after a model instance is deleted
m2m_changed               → a ManyToMany relationship changed
request_started / finished→ request lifecycle
user_logged_in / out      → authentication events
```

## Подключение receiver к signal

```python
from django.db.models.signals import post_save
from django.dispatch import receiver

# automatically create a Profile whenever a User is created
@receiver(post_save, sender=User)
def create_profile(sender, instance, created, **kwargs):
    if created:                          # only on creation, not every save
        Profile.objects.create(user=instance)
```

Декоратор `@receiver` подключает функцию к signal для конкретного отправителя. Когда `User` сохраняется, Django вызывает эту функцию — здесь автоматически создаётся связанный `Profile`. Флаг `created` различает создание от обновления.

## Типичный вариант использования

```python
@receiver(post_save, sender=Order)
def send_order_confirmation(sender, instance, created, **kwargs):
    if created:
        send_email(instance.customer.email, "Order confirmed")
# the Order-creation code doesn't need to know about emails → decoupled
```

Код создания заказа остаётся сфокусированным на заказах; логика отправки email находится отдельно и реагирует на событие — так что concerns остаются разделены.

## Когда signals полезны

```text
✓ Reacting to model events from a DIFFERENT app/module (decoupling)
✓ Auto-creating related objects (Profile on User creation)
✓ Cache invalidation, search-index updates, audit logging on save/delete
✓ Cross-cutting reactions you don't want to embed in the core logic
```

## Важное предостережение: signals могут снизить ясность кода

```python
# ⚠️ signals create IMPLICIT, "action at a distance" behavior:
# saving an Order triggers an email somewhere else — not obvious from the save call.
# This can make code HARDER to follow and debug.
```

```text
When to PREFER explicit code over signals:
  ✗ If the logic clearly belongs in the same flow → call it directly (more readable)
  ✗ Overusing signals → hidden, hard-to-trace behavior, debugging difficulty
  ✓ A common alternative: override the model's save() method, or use a service function,
    for logic tightly coupled to the operation
Use signals mainly for genuine DECOUPLING (reacting across app boundaries), not as
a default for all post-save logic.
```

## Почему это важно

Signals — это полезная функция Django для **разделения кода** — позволяющая разным частям приложения реагировать на события (сохранение/удаление моделей, события аутентификации) без прямых зависимостей, что ценно для cross-cutting concerns вроде автоматического создания связанных объектов, инвалидации кэша, логирования действий и реагирования на события через границы приложений.

Понимание их важно как для *правильного использования* так и для распознавания их в существующих кодовых базах (они часто источник путаницы «почему это произошло?»).

Однако то, что делает signals особенно важной темой — это **нюансированное решение о том, когда их использовать**: хотя они обеспечивают элегантное разделение, они также создают **неявное, «действие на расстоянии» поведение** которое может сделать код сложнее для понимания и отладки (сохранение объекта мистически вызывает эффекты определённые в другом месте).

Опытные Django разработчики понимают этот компромисс — используя signals для *истинного* разделения (реагирование через границы модулей/приложений на события которые не должны быть связаны с источником) при этом предпочитая **явный код** (прямой вызов логики, переопределение `save()` или использование service функций) когда логика явно относится к одному потоку, потому что явный код более читаем и отслеживаем.

Знание того как работают signals (подключение receivers, флаг `created`, распространённые signals), их законные варианты использования и критически **когда их НЕ использовать** (избегая скрытого, сложно отлаживаемого поведения) отражает практическое, опытное понимание которое отличает разработчиков пишущих поддерживаемый Django код от тех кто перегружает signals и создаёт запутанные, непрозрачные приложения.