Django sinyalleri nelerdir?

Question

Accepted Answer

**Sinyaller**, Django'nun gözlemci deseninin uygulanışıdır — belirli olaylar gerçekleştiğinde (bir model kaydedildiğinde veya silindiğinde gibi) belirli göndericilerin bir alıcı kümesine bildirimde bulunmalarını sağlarlar. **Sıkı bağlantıdan arınmış** kodu etkinleştirirler: uygulamanın bir bölümü başka bir bölümdeki olaylara doğrudan bağlantı olmadan tepki verir.

## Yaygın yerleşik sinyaller

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

## Bir alıcıyı sinyale bağlama

```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` dekoratörü bir fonksiyonu belirli bir gönderici için sinyale bağlar. Bir `User` kaydedildiğinde, Django bu fonksiyonu çağırır — burada ilgili bir `Profile` otomatik olarak oluşturur. `created` bayrağı oluşturmayı güncellemelerden ayırır.

## Tipik bir kullanım örneği

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

Sipariş oluşturma kodu siparişlere odaklanmış kalır; e-posta mantığı ayrı olarak yaşar ve olaya tepki verir — kaygıları sıkı bağlantıdan arınmış tutar.

## Sinyallerin ne zaman yararlı olduğu

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

## Önemli uyarı: sinyaller açıklığa zarar verebilir

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

## Neden önemli

Sinyaller, kodu **sıkı bağlantıdan arınmış** tutmanın yararlı bir Django özelliğidir — uygulamanın farklı bölümlerinin (model kaydetme/silme, kimlik doğrulama olayları) doğrudan bağımlılıklar olmadan olaylara tepki vermesini sağlar; bu, otomatik ilgili nesneler oluşturma, önbellek geçersiz kılma, denetim günlüğü ve uygulama sınırları genelinde olaylara tepki verme gibi çapraz kaygılar için değerlidir.

Bunları anlamak hem uygun şekilde *kullanmak* hem de mevcut kod tabanlarında tanımak için önemlidir (bunlar "buna neden oldu?" karışıklığının yaygın bir kaynağıdır).

Bununla birlikte, sinyalleri özellikle önemli bir konu yapan şey, **ne zaman kullanılacağı konusunda incelikli yargılama**dır: uyumlu sıkı bağlantıdan arınmış kodu etkinleştirse de, **örtük, "mesafe-etkisinde" davranış** da oluştururlar ve bu da kodu izlemeyi ve hata ayıklamayı zorlaştırabilir (bir nesneyi kaydetmek gizli şekilde başka yerlerde tanımlanan etkileri tetikler).

Olgun Django geliştiricileri bu takas-off'u anlarlar — *gerçek* sıkı bağlantıdan arınmış olaylara tepki vermek için sinyalleri kullanırlar (kaynağa bağlanmamanız gereken olaylara modül/uygulama sınırları genelinde tepki verme) ve **açık kod**u (mantığı doğrudan çağırma, `save()` geçersiz kılma veya hizmet işlevleri kullanma) tercih ederler, mantık açıkça aynı akışta ait olduğunda, çünkü açık kod daha okunaklı ve izlenebilir.

Sinyallerin nasıl çalıştığını (alıcıları bağlama, `created` bayrağı, yaygın sinyaller), meşru kullanım durumlarını ve kritik olarak **ne zaman KULLANMAYACAĞINI** (gizli, hata ayıklaması zor davranıştan kaçınma) bilmek, uyumlu, deneyimli bir anlayışı yansıtır ve bu da bakımı kolay Django kodu yazan geliştiricileri, sinyalleri aşırı kullanan ve karmaşık, opak uygulamalar yaratan geliştiricilerden ayırır.