Освоение событийно-ориентированного разделения в Laravel

Ваши контроллеры Laravel часто превращаются в свалку бизнес-логики.

Все начинается с простого процесса регистрации. Вскоре вы добавляете email-уведомления, алерты в Slack, журналы аудита и API-вызовы в один единственный метод. Так получается «толстый» контроллер (fat controller).

Толстые контроллеры делают ваш код хрупким. Их сложно тестировать. Они нарушают принцип единственной ответственности (Single Responsibility Principle).

Чтобы исправить это, не нужны сложные инструменты вроде RabbitMQ. В Laravel есть встроенная система событий, которая подходит для большинства задач.

Проблема жесткой связанности (tight coupling): Если API рассылки работает медленно, регистрация пользователя тоже замедляется. Если сервис электронной почты дает сбой, падает весь запрос.

Решение: событийно-ориентированная архитектура (Event-Driven Architecture).

События выступают в роли промежуточного слоя. Ваш контроллер объявляет о действии, а слушатели (listeners) реагируют на это действие независимо друг от друга.

«Тонкий» контроллер выглядит так:

public function register(RegisterRequest $request)
{
    $user = User::create($request->validated());

    UserRegistered::dispatch($user);

    return response()->json(['message' => 'Success'], 201);
}

Теперь контроллер отвечает только за сохранение данных. Его не волнуют побочные эффекты.

Вы получаете три главных преимущества:

  • Производительность: пользователи мгновенно получают ответ. Тяжелые задачи выполняются в фоновом режиме с использованием интерфейса ShouldQueue.
  • Отказоустойчивость: если сервис недоступен, слушатель может повторить задачу, не прерывая работу основного приложения.
  • Расширяемость: вы можете добавлять новые функции, например push-уведомления, просто создавая нового слушателя. При этом исходный контроллер менять не нужно.

Рекомендации (Best practices):

  • Сосредоточьтесь на побочных эффектах: используйте события для постобработки. Не используйте их для основной логики, которая должна выполняться мгновенно.
  • Используйте описательные имена: используйте названия в прошедшем времени, такие как OrderPlaced или UserRegistered. Это указывает на то, что действие уже совершено.
  • Избегайте избыточной абстракции: если фрагмент кода прост и используется в одном месте, вызов функции лучше, чем событие.

Используйте Eloquent Observers для изменений в базе данных. Используйте события (Events) для бизнес-действий.

Рефакторинг с переходом на события — это вопрос долговечности. Это делает ваш код проще в отладке и быстрее в тестировании.

Выберите один «шумный» побочный эффект в вашем контроллере и перенесите его в слушатель уже сегодня.

Попробуйте этот пример в песочнице: https://onlinephp.io/c/1f7b2

За пределами «толстых» контроллеров: освоение событийного разделения в Laravel

В процессе разработки приложений на Laravel разработчики часто сталкиваются с проблемой, когда контроллеры начинают разрастаться, превращаясь в «толстые» контроллеры (Fat Controllers). Хотя это может показаться быстрым способом реализации функционала, со временем это приводит к коду, который трудно поддерживать, тестировать и масштабировать.

В этой статье мы разберем, почему «толстые» контроллеры — это проблема, и как использовать событийную архитектуру для снижения связанности (decoupling) и создания чистого, расширяемого кода.

Проблема: Раздутые контроллеры

Представьте себе типичный метод контроллера, который обрабатывает регистрацию пользователя:

public function register(Request $request)
{
    // 1. Валидация данных
    $validated = $request->validate([
        'name' => 'required|string|max:255',
        'email' => 'required|email|unique:users',
        'password' => 'required|min:8',
    ]);

    // 2. Создание пользователя
    $user = User::create([
        'name' => $validated['name'],
        'email' => $validated['email'],
        'password' => Hash::make($validated['password']),
    ]);

    // 3. Отправка приветственного письма
    Mail::to($user->email)->send(new WelcomeMail($user));

    // 4. Назначение начальной роли
    $user->assignRole('customer');

    // 5. Логирование действия
    Log::info("Новый пользователь зарегистрирован: {$user->email}");

    return response()->json(['message' => 'Регистрация прошла успешно'], 201);
}

На первый взгляд, этот код выглядит логичным. Однако здесь кроется несколько проблем:

  1. Нарушение принципа единственной ответственности (SRP): Контроллер отвечает за валидацию, создание пользователя, отправку почты, управление ролями и логирование. Его задача — только принимать запрос и возвращать ответ.
  2. Сложность тестирования: Чтобы протестировать только логику создания пользователя, вам придется имитировать (mock) отправку почты и работу с ролями.
  3. Низкая масштабируемость: Если завтра вам понадобится отправлять уведомление в Slack или интегрироваться с CRM при регистрации, вам придется снова изменять этот контроллер, увеличивая его сложность.

Решение: Событийно-ориентированная архитектура

Вместо того чтобы заставлять контроллер выполнять все задачи, мы можем использовать События (Events) и Слушатели (Listeners). Контроллер должен лишь сообщать системе: «Эй, произошло событие UserRegistered!», а все остальные части системы сами решат, что с этим делать.

Шаг 1: Создание события и слушателя

Сначала создадим событие с помощью Artisan:

php artisan make:event UserRegistered

Затем создадим слушателя:

php artisan make:listener SendWelcomeEmail --event=UserRegistered

Шаг 2: Реализация события

Событие UserRegistered будет просто контейнером для данных пользователя:

class UserRegistered
{
    use Dispatchable, SerializesModels;

    public $user;

    public function __construct(User $user)
    {
        $this->user = $user;
    }
}

Шаг 3: Реализация слушателей

Теперь мы можем разбить логику на отдельные, независимые слушатели:

Слушатель для отправки почты:

class SendWelcomeEmail
{
    public function handle(UserRegistered $event)
    {
        Mail::to($event->user->email)->send(new WelcomeMail($event->user));
    }
}

Слушатель для назначения ролей:

class AssignCustomerRole
{
    public function handle(UserRegistered $event)
    {
        $event->user->assignRole('customer');
    }
}

Шаг 4: Обновленный контроллер

Теперь наш контроллер выглядит гораздо чище:

public function register(Request $request)
{
    $validated = $request->validate([
        'name' => 'required|string|max:255',
        'email' => 'required|email|unique:users',
        'password' => 'required|min:8',
    ]);

    $user = User::create([
        'name' => $validated['name'],
        'email' => $validated['email'],
        'password' => Hash::make($validated['password']),
    ]);

    // Просто инициируем событие
    event(new UserRegistered($user));

    return response()->json(['message' => 'Регистрация прошла успешно'], 201);
}

Преимущества такого подхода

  1. Снижение связанности (Decoupling): Контроллер больше не знает о существовании почтового сервиса или системы ролей. Он знает только о событии.
  2. Соблюдение SRP: Каждый класс теперь выполняет только одну задачу.
  3. Легкость расширения: Хотите добавить интеграцию с Mailchimp? Просто создайте новый слушатель SyncUserWithMailchimp и привяжите его к событию UserRegistered. Вам не придется менять ни строчки кода в контроллере.
  4. Улучшенная тестируемость: Вы можете тестировать каждый слушатель в изоляции.

Использование очередей (Queues) для производительности

Одним из самых мощных преимуществ событий в Laravel является возможность легко перенести выполнение слушателей в фоновый режим.

Если отправка письма занимает 2-3 секунды, пользователь будет ждать ответа от контроллера всё это время. Чтобы этого избежать, просто реализуйте интерфейс ShouldQueue в вашем слушателе:

class SendWelcomeEmail implements ShouldQueue
{
    // ...
}

Теперь Laravel автоматически поместит задачу по отправке письма в очередь, и контроллер вернет ответ пользователю мгновенно.

Использование Наблюдателей (Observers)

Если вам нужно реагировать на изменения в модели (например, всегда создавать профиль при создании пользователя), рассмотрите использование Observers. Они позволяют отделить логику жизненного цикла модели от контроллеров и даже от самих событий.

php artisan make:observer UserObserver --model=User

Заключение

Переход от «толстых» контроллеров к событийно-ориентированной архитектуре — это важный шаг на пути к профессиональной разработке на Laravel. Это делает ваш код чище, модульным и готовым к изменениям.

Начните с малого: как только вы заметите, что ваш метод в контроллере делает больше одного действия, кроме обработки запроса — это сигнал к созданию события.