掌握 Laravel 中的事件驱动解耦

Translated for your language. 阅读原文.

AI-assisted draft.

前天2分钟阅读

本文目录

𝗠𝗮𝘀𝘁𝗲𝗿𝗶𝗻𝗴 𝗘𝘃𝗲𝗻𝘁-𝗗𝗿𝗶𝘃𝗲𝗻 𝗗𝗲𝗰𝗼𝘂𝗽𝗹𝗶𝗻𝗴 𝗶𝗻 𝗟𝗮𝗿𝗮𝘃𝗲𝗹

Your Laravel controllers often become dumping grounds for business logic.

You start with a simple registration flow. Soon, you add email notifications, Slack alerts, audit logs, and API calls to one single method. This creates a fat controller.

Fat controllers make your code fragile. They are hard to test. They break the Single Responsibility Principle.

You do not need complex tools like RabbitMQ to fix this. Laravel has a built-in event system that works for most needs.

The problem with tight coupling: If a newsletter API is slow, your user registration slows down. If a mail service fails, the entire request fails.

The solution: Event-Driven Architecture.

Events act as a middle layer. Your controller announces an action. Listeners react to that action independently.

A lean controller looks like this:

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

UserRegistered::dispatch($user);

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

}

The controller now only handles data persistence. It does not care about side effects.

You gain three major benefits:

Performance: Users get a response immediately. Heavy tasks run in the background using the ShouldQueue interface.
Resilience: If a service is down, the listener can retry the task without breaking the main application.
Extensibility: You can add new features, like push notifications, by adding a new listener. You do not touch the original controller.

Best practices to follow:

Focus on side effects: Use events for post-processing. Do not use them for core logic that must happen instantly.
Use descriptive names: Use past-tense names like OrderPlaced or UserRegistered. This shows the action already happened.
Avoid over-abstraction: If a piece of code is simple and used in one place, a function call is better than an event.

Use Eloquent Observers for database changes. Use Events for business actions.

Refactoring to events is about durability. It makes your code easier to debug and faster to test.

Pick one noisy side effect in your controller and move it to a listener today.

Try this sandbox example: https://onlinephp.io/c/1f7b2

超越臃肿的控制器：掌握 Laravel 中的事件驱动解耦

你是否曾经查看过你的 Laravel 控制器，然后心想：“天哪，这有点失控了”？你一定遇到过这种情况——控制器长达 500 行，既处理验证、数据库逻辑，又发送邮件、记录日志，甚至可能还在调用第三方 API。这就是我们所说的“臃肿控制器”（Fat Controller）。

问题所在：“臃肿控制器”反模式

随着应用程序的增长，控制器往往会成为所有似乎没有明确归属的逻辑的“垃圾场”。这会导致以下几个问题：

违反单一职责原则 (SRP)： 控制器应该只负责处理 HTTP 请求并返回响应。当它开始管理业务逻辑时，它承担的任务就过多了。
测试困难： 测试一个承担了所有任务的控制器，需要对多个服务进行复杂的 Mock（模拟）。
可维护性差： 修改其中一小块逻辑可能会破坏同一方法内完全无关的其他部分。
代码重复： 如果你需要在另一个控制器或 CLI 命令中使用相同的逻辑，通常只能被迫重复编写代码。

解决方案：事件驱动解耦

与其让控制器编排每一个动作，不如使用 Laravel 的 事件 (Events) 与监听器 (Listeners) 来将核心逻辑与副作用（side effects）解耦。

工作原理

其原理非常简单：

控制器执行主要操作（例如，将用户保存到数据库）。
控制器派发（dispatch）一个事件。
一个或多个 监听器 被该事件触发，从而处理次要任务（例如，发送欢迎邮件、更新仪表板或通知管理员）。

实现指南

1. 创建事件

假设我们要处理新用户注册后发生的事情。首先，我们创建一个事件：

php artisan make:event UserRegistered

UserRegistered 事件类将持有监听器所需的各种数据，例如 User 实例。

2. 创建监听器

现在，让我们创建一个用于发送欢迎邮件的监听器：

php artisan make:listener SendWelcomeEmail --event=UserRegistered

3. 注册事件与监听器

在 Laravel 11（以及最近的版本）中，事件和监听器通常会自动发现。不过，你也可以在 AppServiceProvider 或 EventServiceProvider 中手动注册它们。

4. 在控制器中派发事件

现在，让我们重构控制器。它不再需要处理所有事情，代码现在看起来像这样：

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

    $user = User::create($validated);

    // 不再在这里发送邮件，而是派发一个事件
    UserRegistered::dispatch($user);

    return redirect()->route('dashboard')->with('success', 'Registration successful!');
}

这种方法的优势

逻辑解耦

控制器不再关心用户是如何被通知的，也不关心注册后会发生什么。它只关心用户是否已注册。这使得代码更加简洁，且更易于理解。

可扩展性与队列

这是最强大的地方。由于副作用是在监听器中处理的，你可以轻松地将它们移至 队列 (Queue)。通过在监听器上实现 ShouldQueue 接口，Laravel 会自动将该任务推送到你的后台工作进程中。

class SendWelcomeEmail implements ShouldQueue
{
    // ...
}

这确保了用户的请求不会因为发送邮件等缓慢的过程而产生延迟。

更容易测试

你现在可以测试 store 方法，只需断言 UserRegistered 事件已被派发，而无需担心邮件是否真的发送成功。

总结

从“臃肿控制器”转向事件驱动架构是 Laravel 应用程序走向成熟的标志。它提高了可维护性、可测试性和可扩展性，让你的应用程序在增长时不会变成一团乱麻。