Hvad er Django-signaler?

Question

IT Interview Practice · Accepted Answer

**Signaler** er Djangos implementering af observatør-mønsteret — de lader bestemte afsendere underrette en gruppe modtagere, når specifikke **begivenheder** opstår (som når en model gemmes eller slettes). De muliggør **afkoblet** kode: en del af appen reagerer på begivenheder i en anden uden direkte kobling.

## Almindelige indbyggede signaler

```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
```

## Forbindelse af en modtager til et 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)
```

Dekoratøren `@receiver` forbinder en funktion til et signal for en bestemt afsender. Når en `User` gemmes, kalder Django denne funktion — her oprettes automatisk en relateret `Profile`. Flaget `created` skelner mellem oprettelse og opdateringer.

## Et typisk use case

```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
```

Koden, der opretter ordrer, fokuserer på ordrer; e-mail-logikken lever separat og reagerer på begivenheden — hvilket holder bekymringerne afkoblede.

## Hvornår signaler er nyttige

```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
```

## Den vigtige advarsel: signaler kan skade klarhed

```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.
```

## Hvorfor det betyder noget

Signaler er en nyttig Django-funktion til **afkobling** af kode — der lader forskellige dele af en applikation reagere på begivenheder (model-gemte/sletninger, auth-begivenheder) uden direkte afhængigheder, hvilket er værdifuldt for tværgående bekymringer som automatisk oprettelse af relaterede objekter, cache-invalidering, revisionlogging og reaktion på begivenheder på tværs af app-grænser.

Det er vigtigt at forstå dem både for *at bruge* dem passende og for at genkende dem i eksisterende kodebaser (de er en almindelig kilde til "hvorfor skete dette?" forvirring).

Men det, der gør signaler til et særligt vigtigt emne, er **nuanceret vurdering af hvornår man skal bruge dem**: selvom de muliggør elegant afkobling, skaber de også **implicit, "handling-på-afstand"-adfærd**, der kan gøre koden sværere at følge og fejlrette (gemning af et objekt udløser mysterisk effekter defineret andetsteds).

Modne Django-udviklere forstår denne afvejning — bruger signaler til *ægte* afkobling (reaktion på tværs af modul-/app-grænser til begivenheder, du ikke burde koble til kilden) mens de foretrækker **eksplicit kode** (kalder logik direkte, tilsidesætter `save()`, eller bruger servicefunktioner), når logikken klart hører til i samme flow, fordi eksplicit kode er mere læsbar og sporbar.

At vide, hvordan signaler fungerer (forbindelse af modtagere, flaget `created`, almindelige signaler), deres legitime use cases, og især **hvornår man IKKE skal bruge dem** (undgå skjult, svært fejlretteligt adfærd) afspejler praktisk, erfaren forståelse, der skelner udviklere, der skriver vedligeholdelig Django-kode, fra dem, der misbruger signaler og skaber usammenhængende, uigennemsigtige applikationer.

Almindelige indbyggede signaler

Forbindelse af en modtager til et signal

Et typisk use case

Hvornår signaler er nyttige

Den vigtige advarsel: signaler kan skade klarhed

Hvorfor det betyder noget

Relaterede spørgsmål