Django signal là gì?

Question

Accepted Answer

**Signal** là cách Django hiện thực observer pattern — chúng cho phép một số sender thông báo cho một tập các receiver khi các **sự kiện** cụ thể xảy ra (như một model được lưu hoặc xóa). Chúng cho phép mã **tách rời (decoupled)**: một phần của app phản ứng với sự kiện ở phần khác mà không có sự gắn kết trực tiếp.

## Các signal tích hợp phổ biến

```text
pre_save / post_save      → trước / sau khi một instance của model được lưu
pre_delete / post_delete  → trước / sau khi một instance của model bị xóa
m2m_changed               → một quan hệ ManyToMany thay đổi
request_started / finished→ vòng đời request
user_logged_in / out      → sự kiện xác thực
```

## Kết nối một receiver với một signal

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

# tự động tạo một Profile mỗi khi một User được tạo
@receiver(post_save, sender=User)
def create_profile(sender, instance, created, **kwargs):
    if created:                          # chỉ khi tạo, không phải mỗi lần lưu
        Profile.objects.create(user=instance)
```

Decorator `@receiver` kết nối một hàm với một signal cho một sender cụ thể. Khi một `User` được lưu, Django gọi hàm này — ở đây, tự động tạo một `Profile` liên quan. Cờ `created` phân biệt việc tạo với việc cập nhật.

## Một use case điển hình

```python
@receiver(post_save, sender=Order)
def send_order_confirmation(sender, instance, created, **kwargs):
    if created:
        send_email(instance.customer.email, "Order confirmed")
# mã tạo Order không cần biết về email → tách rời
```

Mã tạo order vẫn tập trung vào order; logic email nằm riêng và phản ứng với sự kiện — giữ các mối quan tâm tách rời.

## Khi nào signal hữu ích

```text
✓ Phản ứng với sự kiện model từ một app/module KHÁC (tách rời)
✓ Tự động tạo đối tượng liên quan (Profile khi tạo User)
✓ Vô hiệu hóa cache, cập nhật search-index, audit logging khi lưu/xóa
✓ Các phản ứng xuyên suốt mà bạn không muốn nhúng vào logic cốt lõi
```

## Lưu ý quan trọng: signal có thể làm giảm sự rõ ràng

```python
# ⚠️ signal tạo ra hành vi NGẦM ĐỊNH, "hành động từ xa":
# lưu một Order kích hoạt một email ở đâu đó khác — không rõ ràng từ lệnh gọi save.
# Điều này có thể khiến mã KHÓ theo dõi và gỡ lỗi hơn.
```

```text
Khi nào nên ƯU TIÊN mã rõ ràng hơn signal:
  ✗ Nếu logic rõ ràng thuộc về cùng luồng → gọi nó trực tiếp (dễ đọc hơn)
  ✗ Lạm dụng signal → hành vi ẩn, khó truy vết, khó gỡ lỗi
  ✓ Một thay thế phổ biến: ghi đè phương thức save() của model, hoặc dùng một hàm service,
    cho logic gắn chặt với thao tác
Dùng signal chủ yếu cho việc TÁCH RỜI thực sự (phản ứng xuyên ranh giới app), không phải
làm mặc định cho mọi logic post-save.
```

## Tại sao điều này quan trọng

Signal là một tính năng Django hữu ích để **tách rời** mã — cho phép các phần khác nhau của ứng dụng phản ứng với sự kiện (lưu/xóa model, sự kiện auth) mà không có phụ thuộc trực tiếp, điều có giá trị cho các mối quan tâm xuyên suốt như tự động tạo đối tượng liên quan, vô hiệu hóa cache, audit logging, và phản ứng với sự kiện xuyên ranh giới app.

Hiểu chúng quan trọng cả để *dùng* chúng phù hợp lẫn để nhận diện chúng trong codebase hiện có (chúng là nguồn phổ biến của sự bối rối "tại sao điều này lại xảy ra?").

Tuy nhiên, điều khiến signal trở thành một chủ đề đặc biệt quan trọng là **sự phán đoán tinh tế về khi nào nên dùng chúng**: dù chúng cho phép tách rời thanh lịch, chúng cũng tạo ra **hành vi ngầm định, "hành động từ xa"** có thể khiến mã khó theo dõi và gỡ lỗi hơn (lưu một đối tượng bí ẩn kích hoạt các tác động được định nghĩa ở nơi khác).

Các lập trình viên Django trưởng thành hiểu đánh đổi này — dùng signal cho việc tách rời *thực sự* (phản ứng xuyên ranh giới module/app với các sự kiện bạn không nên gắn kết với nguồn) trong khi ưu tiên **mã rõ ràng** (gọi logic trực tiếp, ghi đè `save()`, hoặc dùng hàm service) khi logic rõ ràng thuộc về cùng luồng, vì mã rõ ràng dễ đọc và truy vết hơn.

Biết cách signal hoạt động (kết nối receiver, cờ `created`, các signal phổ biến), các use case chính đáng của chúng, và quan trọng là **khi nào KHÔNG dùng chúng** (tránh hành vi ẩn, khó gỡ lỗi) phản ánh hiểu biết thực tế, dày dạn phân biệt các lập trình viên viết mã Django dễ bảo trì với những người lạm dụng signal và tạo ra các ứng dụng rối rắm, mờ đục.