Service Providers : architecture modulaire avec Laravel

Le rôle des Service Providers

Chaque requête Laravel commence par le bootstrap de l'application. Les Service Providers sont responsables de l'enregistrement de tous les composants : bindings du container, event listeners, middleware, routes. C'est le point central de configuration de votre application.

Laravel charge les providers déclarés dans config/app.php en deux phases distinctes : register puis boot. Cette séparation est cruciale pour éviter les dépendances circulaires.

Les deux phases : Register vs Boot

Phase Register

La méthode register() sert uniquement à lier des classes au container. À ce stade, aucun autre service n'est garanti d'être disponible. Règle d'or : ne jamais utiliser d'autre service dans register().

                

                    

                    app/Providers/PaymentServiceProvider.php
                
                class PaymentServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        // Binding simple
        $this->app->bind(
            PaymentGatewayInterface::class,
            StripePaymentGateway::class
        );

        // Singleton avec configuration
        $this->app->singleton(PaymentService::class, function ($app) {
            return new PaymentService(
                $app->make(PaymentGatewayInterface::class),
                config('payment.currency')
            );
        });
    }
}
            

Phase Boot

La méthode boot() est appelée après que tous les providers ont été enregistrés. Vous pouvez utiliser n'importe quel service, enregistrer des routes, des vues, des event listeners.

                

                    

                    app/Providers/PaymentServiceProvider.php
                
                public function boot(): void
{
    // Charger les routes du module
    $this->loadRoutesFrom(__DIR__.'/../routes/payment.php');

    // Publier la configuration
    $this->publishes([
        __DIR__.'/../config/payment.php' => config_path('payment.php'),
    ], 'payment-config');

    // Enregistrer un event listener
    Event::listen(
        PaymentCompleted::class,
        SendPaymentNotification::class
    );
}
            

Deferred Providers : optimiser les performances

Par défaut, tous les providers sont chargés à chaque requête. Pour les services rarement utilisés, le deferred loading permet de ne charger le provider que lorsque le service est effectivement demandé.

                

                    

                    app/Providers/ReportServiceProvider.php
                
                class ReportServiceProvider extends ServiceProvider
{
    // Ce provider ne sera chargé que si ReportGenerator est demandé
    protected $defer = true;

    public function register(): void
    {
        $this->app->singleton(ReportGenerator::class, function ($app) {
            return new ReportGenerator(
                $app->make(PdfRenderer::class)
            );
        });
    }

    // Déclarer les services fournis
    public function provides(): array
    {
        return [ReportGenerator::class];
    }
}
            

Pattern : Domain Service Provider

Pour les applications complexes, regrouper les bindings par domaine métier plutôt que par type technique améliore la lisibilité et la maintenabilité.

                

                    

                    app/Providers/OrderDomainServiceProvider.php
                
                class OrderDomainServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        // Repository
        $this->app->bind(
            OrderRepositoryInterface::class,
            EloquentOrderRepository::class
        );

        // Services métier
        $this->app->singleton(OrderService::class);
        $this->app->singleton(OrderPricingService::class);

        // Factories
        $this->app->bind(OrderFactory::class);
    }

    public function boot(): void
    {
        // Observers
        Order::observe(OrderObserver::class);

        // Policies
        Gate::policy(Order::class, OrderPolicy::class);
    }
}
            

Cette approche permet de voir d'un coup d'œil tout ce qui concerne le domaine "Order". Lors d'un refactoring ou d'un debug, vous savez exactement où chercher.

Contextual Binding : adapter selon le contexte

Le contextual binding permet d'injecter des implémentations différentes selon la classe qui demande la dépendance. Utile pour adapter le comportement sans multiplier les interfaces.

                

                    

                    app/Providers/AppServiceProvider.php
                
                public function register(): void
{
    // Les controllers web utilisent le cache Redis
    $this->app->when(WebController::class)
        ->needs(CacheInterface::class)
        ->give(RedisCache::class);

    // Les jobs queue utilisent le cache fichier (plus fiable)
    $this->app->when(ProcessOrderJob::class)
        ->needs(CacheInterface::class)
        ->give(FileCache::class);

    // Injection de valeurs primitives
    $this->app->when(SlackNotifier::class)
        ->needs('$webhookUrl')
        ->give(config('services.slack.webhook'));
}
            

Tester avec des Service Providers

L'avantage majeur des Service Providers : la possibilité de remplacer les implémentations en test. Plus besoin de mocker des facades ou de hacker le code.

                

                    

                    tests/Feature/PaymentTest.php
                
                class PaymentTest extends TestCase
{
    protected function setUp(): void
    {
        parent::setUp();

        // Remplacer le gateway par un fake
        $this->app->bind(
            PaymentGatewayInterface::class,
            FakePaymentGateway::class
        );
    }

    public function test_payment_is_processed(): void
    {
        $gateway = $this->app->make(PaymentGatewayInterface::class);

        $result = $gateway->charge('tok_visa', 1000);

        $this->assertTrue($result->successful());
        $this->assertEquals(1000, $gateway->totalCharges());
    }
}
            

Bonnes pratiques

• Un provider par domaine : plutôt que par type technique (repositories, services...)
• Register = bindings uniquement : pas de logique, pas d'appels à d'autres services
• Boot = tout le reste : events, routes, observers, policies
• Interfaces pour les services externes : facilite le remplacement et les tests
• Éviter les singletons sauf nécessité : ils complexifient les tests et peuvent créer des effets de bord
• Documenter les provides() : pour le deferred loading, listez clairement les services fournis

Pour aller plus loin

• Documentation Laravel : Service Container & Service Providers
• Livre : "Laravel: Up & Running" - Matt Stauffer
• Concept : Dependency Injection et Inversion of Control
• Pattern : Repository Pattern avec interfaces