Laravel采用Repository Pattern时，事件、邮件与通知代码应置于何处？

Great question! This is a common point of confusion when implementing the Repository Pattern in Laravel, so let's break down the best practices and why they matter.

First: What's the Repository's Core Job? #

The whole point of the Repository Pattern is to separate data access logic from business logic. Repositories act as a clean layer between your app and the database—their only job is handling CRUD operations, querying data, and hiding details like which database driver you’re using. They should never be responsible for side effects like sending emails, firing events, or sending notifications.

So Where Should This Code Live? #

It depends on how complex your workflow is, but here are the most practical approaches:

1. Controllers (For Simple Workflows) #

If your logic is straightforward—like sending a welcome email right after a user registers—placing this code directly in the controller is totally fine. Controllers are meant to handle HTTP requests, coordinate small actions, and return responses, so a few lines of event/notification code here won’t clutter things up.

Example:

class UserController extends Controller
{
    public function store(Request $request, UserRepository $userRepo)
    {
        $validated = $request->validate([
            'name' => 'required|string',
            'email' => 'required|email|unique:users',
            'password' => 'required|min:8',
        ]);

        // Let the repository handle data creation only
        $user = $userRepo->create($validated);

        // Trigger event for post-registration actions
        UserRegistered::dispatch($user);

        // Send a direct notification
        $user->notify(new WelcomeNotification());

        return redirect()->route('dashboard')->with('success', 'Account created!');
    }
}

2. Service Classes (For Complex Business Logic) #

If your workflow involves multiple steps—like registering a user, updating a subscription, logging analytics, and sending three different notifications—controllers can quickly become bloated. This is where service classes come in handy. They encapsulate your core business logic, keeping controllers lean and making your code easier to reuse and test.

Example Service Class:

class UserRegistrationService
{
    public function __construct(private UserRepository $userRepo) {}

    public function register(array $userData): User
    {
        // Create user via repository (data access only)
        $user = $this->userRepo->create($userData);

        // Handle all business-related side effects here
        UserRegistered::dispatch($user);
        $user->notify(new WelcomeNotification());
        $this->updateRegistrationAnalytics();
        $this->alertAdminsOfNewUser($user);

        return $user;
    }

    private function updateRegistrationAnalytics(): void
    {
        // Logic to increment monthly registration stats
    }

    private function alertAdminsOfNewUser(User $user): void
    {
        // Logic to send an alert email to admins
    }
}

Then in your controller:

class UserController extends Controller
{
    public function store(Request $request, UserRegistrationService $registrationService)
    {
        $validated = $request->validate([/* ... */]);
        $user = $registrationService->register($validated);

        return redirect()->route('dashboard')->with('success', 'Account created!');
    }
}

3. Event Listeners (For Decoupled Side Effects) #

Laravel’s event system is perfect for decoupling actions. Instead of handling emails/notifications directly in your controller or service, fire an event, and let dedicated listeners handle the side effects. This makes it easy to add or remove actions later without touching your core business logic.

Example:

// In your controller/service
UserRegistered::dispatch($user);

// Event class
class UserRegistered
{
    use Dispatchable, InteractsWithSockets, SerializesModels;

    public function __construct(public User $user) {}
}

// Listener for sending welcome email
class SendWelcomeEmail
{
    public function handle(UserRegistered $event): void
    {
        Mail::to($event->user)->send(new WelcomeEmail($event->user));
    }
}

// Listener for sending in-app notification
class SendWelcomeNotification
{
    public function handle(UserRegistered $event): void
    {
        $event->user->notify(new WelcomeNotification());
    }
}

Why Not Put This in the Repository? #

• Single Responsibility Principle: Repositories should only manage data access. Mixing in event/email logic breaks this principle, making your code harder to maintain and debug.
• Testability: Testing a repository should only involve verifying data is saved/retrieved correctly. If it includes email logic, you’ll have to mock mail services just to test basic CRUD operations—unnecessary extra work.
• Flexibility: If you later decide to stop sending welcome emails, or switch to a different notification service, you shouldn’t have to modify your repository code. Separating concerns lets you make changes without disrupting the data layer.

内容的提问来源于stack exchange，提问作者Hamza Alayed