Начальный

Роутинг, контроллеры и шаблоны

Урок 2 из 3 в курсе Веб-фреймворк: как он устроен

Содержание курса (2/3)

Роутинг, контроллеры и шаблоны

фреймворк связывает URL с кодом через маршруты и контроллеры, а ответ формирует через шаблоны или сериализаторы.

Почему это важно: Это сердце любого веб-приложения. Понимание потока запроса помогает отлаживать любые ошибки.

Главная идея

URL → роутер → контроллер → модель → шаблон/JSON → ответ. Каждое звено делает одну задачу.

Как это выглядит на практике

  1. Запрос GET /posts/42 приходит на сервер.
  2. Роутер сопоставляет URL с действием PostsController#show.
  3. Контроллер загружает пост из БД через модель.
  4. Шаблон или сериализатор формирует HTML/JSON.
  5. Ответ возвращается клиенту.

Что происходит под капотом

  • RESTful routing: семь стандартных действий — index, show, new, create, edit, update, destroy.
  • Параметры URL (path params) отличаются от query-параметров: /users/:id vs /users?id=42.
  • Контроллеры должны быть 'тонкими' — бизнес-логика лежит в моделях/сервисах.
  • Шаблоны (ERB, Jinja, JSX) отделяют представление от логики.

Типичные ошибки и заблуждения

  • Ошибка: всю логику можно класть в контроллер. Это превращает его в 'бог-объект'.
  • Ошибка: шаблоны не влияют на производительность. N+1 запросы часто начинаются именно в них.
  • Ошибка: REST = обязательные 7 действий. Это частый шаблон, а не жёсткое требование.
  • Ошибка: роутер — простая таблица. В крупных приложениях это иерархическая структура с namespace и scope.

Ключевые выводы

  • Контроллер — оркестратор, а не место для бизнес-логики.
  • RESTful conventions делают API предсказуемым.
  • Шаблоны должны быть без логики кроме отображения.
  • Path params vs query params — разные инструменты для разных задач.

Термины урока

Route: правило сопоставления URL с обработчиком.
Action: метод контроллера, обрабатывающий запрос.
Params: параметры запроса (path, query, body).
Partial: переиспользуемый фрагмент шаблона.

Связь с работой backend-разработчика

Чистая связка роутинг → контроллер → модель → шаблон делает приложение легко поддерживаемым и тестируемым.

Мини-разбор реальной ситуации

В контроллере показа товара росла логика: скидки, наличие, рекомендации, аналитика. Контроллер стал на 400 строк. После выноса в сервисные объекты его объём сократился до 15 строк, а тесты стали в разы быстрее.

Что запомнить

  • Fat model, skinny controller.
  • REST — это шаблон, а не догма.
  • Шаблоны — для отображения, не для логики.

Итог

Поток 'запрос → роутер → контроллер → модель → шаблон' — основа любого веб-фреймворка.

Комментарии к уроку

Войдите, чтобы оставить комментарий.

Пока нет комментариев — будьте первым.