Django signal คืออะไร?

Question

IT Interview Practice · Accepted Answer

**Signal** คือการนำ observer pattern มาใช้ของ Django — มันให้ sender บางตัวแจ้งเตือน receiver ชุดหนึ่งเมื่อมี **เหตุการณ์** เฉพาะเกิดขึ้น (เช่น model ถูกบันทึกหรือถูกลบ) ทำให้เกิดโค้ดที่ **แยกการพึ่งพากัน** (decoupled): ส่วนหนึ่งของแอปตอบสนองต่อเหตุการณ์ในอีกส่วนหนึ่งโดยไม่ต้องผูกติดกันโดยตรง

## Signal สำเร็จรูปที่พบบ่อย

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

decorator `@receiver` เชื่อมฟังก์ชันเข้ากับ signal สำหรับ sender ที่ระบุ เมื่อ `User` ถูกบันทึก Django จะเรียกฟังก์ชันนี้ — ในที่นี้คือการสร้าง `Profile` ที่เกี่ยวข้องโดยอัตโนมัติ flag `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
```

โค้ดที่สร้าง order ยังคงโฟกัสที่ order ส่วนตรรกะของอีเมลอยู่แยกต่างหากและตอบสนองต่อเหตุการณ์ — รักษาให้แต่ละส่วนแยกการพึ่งพากัน

## เมื่อใด signal มีประโยชน์

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

## ข้อควรระวังสำคัญ: signal อาจทำให้ความชัดเจนเสียไป

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

## ทำไมจึงสำคัญ

signal เป็นฟีเจอร์ที่มีประโยชน์ของ Django สำหรับ **การแยกการพึ่งพากัน** ของโค้ด — ให้ส่วนต่าง ๆ ของแอปพลิเคชันตอบสนองต่อเหตุการณ์ (การบันทึก/ลบ model, เหตุการณ์ auth) โดยไม่มีการพึ่งพากันโดยตรง ซึ่งมีค่าสำหรับประเด็นแบบ cross-cutting เช่นการสร้าง object ที่เกี่ยวข้องโดยอัตโนมัติ, การ invalidate cache, การ audit logging และการตอบสนองต่อเหตุการณ์ข้ามขอบเขตของแอป

การเข้าใจมันสำคัญทั้งสำหรับการ *ใช้* อย่างเหมาะสมและสำหรับการรู้จักมันในโค้ดเบสที่มีอยู่ (มันเป็นแหล่งความสับสน "ทำไมสิ่งนี้ถึงเกิดขึ้น?" ที่พบบ่อย)

อย่างไรก็ตาม สิ่งที่ทำให้ signal เป็นหัวข้อสำคัญเป็นพิเศษคือ **วิจารณญาณที่ละเอียดอ่อนเกี่ยวกับว่าเมื่อใดควรใช้**: แม้ว่ามันจะเปิดทางให้แยกการพึ่งพากันได้อย่างสง่างาม แต่มันก็สร้าง **พฤติกรรมแบบโดยปริยายที่ "ทำงานจากระยะไกล"** (action at a distance) ซึ่งอาจทำให้โค้ดติดตามและดีบักได้ยากขึ้น (การบันทึก object กลับกระตุ้นผลกระทบที่นิยามไว้ที่อื่นอย่างลึกลับ)

นักพัฒนา Django ที่มีประสบการณ์เข้าใจ trade-off นี้ — ใช้ signal สำหรับการแยกการพึ่งพากัน *อย่างแท้จริง* (ตอบสนองข้ามขอบเขตของ module/app ต่อเหตุการณ์ที่คุณไม่ควรผูกติดกับต้นทาง) ในขณะที่เลือกใช้ **โค้ดที่ชัดเจน** (เรียกตรรกะโดยตรง, override `save()`, หรือใช้ service function) เมื่อตรรกะนั้นชัดเจนว่าควรอยู่ในขั้นตอนเดียวกัน เพราะโค้ดที่ชัดเจนอ่านและติดตามได้ง่ายกว่า

การรู้ว่า signal ทำงานอย่างไร (การเชื่อม receiver, flag `created`, signal ที่พบบ่อย), กรณีการใช้งานที่ถูกต้อง และที่สำคัญคือ **เมื่อใดไม่ควรใช้** (หลีกเลี่ยงพฤติกรรมที่ซ่อนเร้นและดีบักยาก) สะท้อนความเข้าใจเชิงปฏิบัติที่มาจากประสบการณ์ ซึ่งแยกแยะนักพัฒนาที่เขียนโค้ด Django ที่ดูแลรักษาได้ ออกจากผู้ที่ใช้ signal มากเกินไปและสร้างแอปพลิเคชันที่ยุ่งเหยิงและคลุมเครือ

Signal สำเร็จรูปที่พบบ่อย

การเชื่อม receiver เข้ากับ signal

กรณีการใช้งานทั่วไป

เมื่อใด signal มีประโยชน์

ข้อควรระวังสำคัญ: signal อาจทำให้ความชัดเจนเสียไป

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง