Kaip veikia užklausos gyvavimo ciklas Django?

Question

IT Interview Practice · Accepted Answer

Django užklausą apdoroja **WSGI/ASGI handler**, ją apgaubia **middleware** krūva, ją nukreipia **URL resolver** į **view**, o rezultatas paverčiamas `HttpResponse`, kuris teka atgal per tuos pačius middleware atvirkštine tvarka.

## Etapai

```
Web serveris ──▶ WSGI/ASGI handler  (sukuria HttpRequest)
   ▼
Middleware — užklausos fazė        (viršus → apačia: __call__ prieš get_response)
   ▼
URL resolver (urls.py)  ── suderina path → view + kwargs
   ▼
Middleware — process_view hook
   ▼
View (funkcija / class-based)  ── jūsų logika, grąžina HttpResponse
   ▼
Middleware — atsakymo fazė          (apačia → viršus: po get_response)
   ▼
HttpResponse ──▶ klientas
```

1. **Handler** — WSGI (sinchroninis) arba ASGI (asinchroninis) handler sukonstruoja `HttpRequest` iš environ/scope.
2. **Middleware, užklausos fazė** — kiekvieno middleware kodas *prieš* `get_response()` vykdomas iš viršaus į apačią (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Bet kuris iš jų gali nutraukti anksčiau ir grąžinti atsakymą iš karto.
3. **URL resolution** — `ROOT_URLCONF` šablonai suderinami su path, siekiant parinkti view ir pagauti kwargs.
4. **`process_view`** — middleware hook, vykdomas iškart prieš iškviečiant view.
5. **View** — jūsų funkcijos ar klasės pagrindu sukurtas view įvykdomas, paprastai užklausiant modelius ir renderinant šabloną (template), ir grąžina `HttpResponse`. Išimtys (exceptions) iššaukia `process_exception`.
6. **Middleware, atsakymo fazė** — kodas *po* `get_response()` vykdomas iš apačios į viršų, leisdamas middleware modifikuoti išeinantį atsakymą (antraštes, suspaudimą).
7. `HttpResponse` yra srautu grąžinamas į serverį ir klientą.

```python
# middleware.py
class TimingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

def __call__(self, request):          # 2. užklausos fazė (prieš)
        request.started = time.monotonic()
        response = self.get_response(request)  # iškviečia kitą sluoksnį / view
        response["X-Time"] = "..."         # 6. atsakymo fazė (po)
        return response

# urls.py  → 3. routing
urlpatterns = [path("items/<int:pk>/", views.item_detail)]

# views.py → 5. view
def item_detail(request, pk):
    return render(request, "item.html", {"item": Item.objects.get(pk=pk)})
```

## Kodėl tai svarbu

Django užklausos/atsakymo ciklas yra sutelktas į middleware, todėl didžioji dalis kertinio (cross-cutting) elgesio — auth, sesijos, CSRF, security antraštės, caching — įgyvendinama kaip sutvarkytas middleware. Supratimas, kad užklausos fazės kodas vykdomas iš viršaus į apačią, o atsakymo fazės kodas iš apačios į viršų (ir kad eiliškumas `MIDDLEWARE` yra svarbus), yra esminis, norint teisingai išdėstyti savo middleware, suprasti (debug), kodėl `403`/nukreipimas (redirect) įvyksta prieš jūsų view, ir žinoti, kur prikabinti logiką neliečiant kiekvieno view.

Etapai

Kodėl tai svarbu

Susiję klausimai