Laravel多Action类型数据转字符串的最优方案及代码存放位置咨询

Great question! When you need to handle tons of different action types and convert event data into human-readable strings, the Strategy Pattern paired with Laravel's service container is hands down the cleanest, most maintainable approach. It keeps your code organized, scalable, and aligned with Laravel's design principles. Let me break this down step by step.

Step 1: Define a Contract (Interface) #

First, create an interface to standardize all your action formatters. This ensures every formatter follows the same structure, making it easy to add new ones later.

// app/Contracts/ActionFormatterInterface.php
namespace App\Contracts;

interface ActionFormatterInterface
{
    /**
     * Convert event data to a human-readable string
     *
     * @param array $data
     * @return string
     */
    public function format(array $data): string;
}

Step 2: Create Strategy Classes for Each Action #

For every action type (like PushEvent, CreateEvent, etc.), build a dedicated formatter class that implements the interface. Each class handles only one action's logic—keeping things focused and easy to test.

// app/Formatters/Action/PushEventFormatter.php
namespace App\Formatters\Action;

use App\Contracts\ActionFormatterInterface;

class PushEventFormatter implements ActionFormatterInterface
{
    public function format(array $data): string
    {
        return "User pushed {$data['commits_count']} commits to {$data['repository']['name']}";
    }
}

Add more formatters as needed (e.g., CreateEventFormatter for repo creation events, IssueCommentEventFormatter for comment actions, etc.).

Step 3: Build a Central Formatter Service #

Create a service class that maps action types to their corresponding formatters and handles resolving the right class. This is the single entry point you'll use in your app to format event data.

// app/Services/ActionFormatter.php
namespace App\Services;

use App\Contracts\ActionFormatterInterface;
use InvalidArgumentException;

class ActionFormatter
{
    // Map action types to their formatter classes
    protected $formatterMap = [
        'PushEvent' => \App\Formatters\Action\PushEventFormatter::class,
        'CreateEvent' => \App\Formatters\Action\CreateEventFormatter::class,
        // Add more actions here as you expand
    ];

    public function format(array $eventData): string
    {
        // Validate the action exists in the data
        $action = $eventData['action'] ?? throw new InvalidArgumentException('Event data missing "action" field');

        // Make sure we have a formatter for this action
        if (!isset($this->formatterMap[$action])) {
            throw new InvalidArgumentException("No formatter available for action: {$action}");
        }

        // Resolve the formatter via Laravel's service container and run the format method
        /** @var ActionFormatterInterface $formatter */
        $formatter = app($this->formatterMap[$action]);
        
        return $formatter->format($eventData);
    }
}

Step 4: Use the Service in Your Application #

Call the service wherever you need to convert event data to a string—controllers, jobs, listeners, or even blade views:

// Example usage in a controller or job
$eventData = [
    "action" => "PushEvent",
    "commits_count" => 5,
    "repository" => ["name"=>"example-repo"]
];

$formattedString = app(\App\Services\ActionFormatter::class)->format($eventData);
// Output: "User pushed 5 commits to example-repo"

Bonus: Make It Even More Flexible #

To avoid modifying the service class every time you add a new action, move the formatter map to a config file. This keeps configuration separate from your business logic:

// config/action_formatters.php
return [
    'PushEvent' => \App\Formatters\Action\PushEventFormatter::class,
    'CreateEvent' => \App\Formatters\Action\CreateEventFormatter::class,
    // Add new actions here
];

Then update the service class to use the config:

// In app/Services/ActionFormatter.php
public function __construct()
{
    $this->formatterMap = config('action_formatters');
}

Why This Works So Well for Laravel #

• Open/Closed Principle: Add new actions without touching existing code—just create a new formatter and update the map/config.
• Single Responsibility: Each formatter handles one action's logic, making code easy to debug and test.
• Leverages Laravel's Service Container: Automatically resolves dependencies if your formatters need them (e.g., a logger or database connection).

Where to Store Your Code #

• Interface: app/Contracts/ – Laravel's standard location for "contracts" (interfaces that define behavior).
• Formatter Classes: app/Formatters/Action/ – A dedicated subdirectory keeps related files organized. You could also use app/Strategies/Action/ if you prefer that naming.
• Service Class: app/Services/ – The go-to spot for reusable business logic services in Laravel.
• Config File: config/ – Storing the action-to-formatter map here keeps configuration separate from code.

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