Google+
4elements web design & consultancy

Shineyrock

web design & consultancy
Shineyrock web design & consultancy

Shineyrock

  1. web design en consultancy

blog

  1. Home
  2. blog
  3. lees
  4. How to Register and Use Laravel Service Providers
  • like 7 01

    How to Register and Use Laravel Service Providers

    1. June 2017
    2. Daily
    3. gelezen 0

    If you've ever used the Laravel framework, you've probably heard of service containers and service providers. In fact, they're the backbone of the Laravel framework and do all the heavy lifting when you launch an instance of any Laravel application.

    In this article, we're going to have a glimpse of what the service container is all about, and following that we'll discuss the service provider in detail. In the course of this article, I'll also demonstrate how to create a custom service provider in Laravel. Once you create a service provider, you also need to register it with the Laravel application in order to actually use it, so we'll go through that as well.

    There are two important methods, boot and register, that your service provider may implement, and in the last segment of this article we'll discuss these two methods thoroughly.

    Before we dive into the discussion of a service provider, I'll try to introduce the service container as it will be used heavily in your service provider implementation.

    Understand Service Containers and Service Providers

    What Is a Service Container?

    In the simplest terms, we could say that the service container in Laravel is a box that holds various components' bindings, and they are served as needed throughout the application.

    In the words of the official Laravel documentation:

    The Laravel service container is a powerful tool for managing class dependencies and performing dependency injection.

    So whenever you need to inject any built-in component or service, you could type hint it in your constructor or method, and it'll be injected automatically from the service container as it contains everything you need! Isn't that cool? It saves you from manually instantiating the components and thus avoids tight coupling in your code.

    Let's have a look at a quick example to understand it.

    Class SomeClass
{
    public function __construct(FooBar $foobarObject)
    {
        // use $foobarObject object
    }
}

    As you can see, the SomeClass needs an instance of FooBar to instantiate itself. So, basically, it has a dependency that needs to be injected. Laravel does this automatically by looking into the service container and injecting the appropriate dependency.

    And if you're wondering how Laravel knows which components or services to include in the service container, the answer is the service provider. It's the service provider that tells Laravel to bind various components into the service container. In fact, it's called service container bindings, and you need to do it via the service provider.

    So it's the service provider that registers all the service container bindings, and it's done via the register method of the service provider implementation.

    That should raise another question: how does Laravel know about various service providers? Perhaps you think Laravel should figure that out automatically too? Unfortunately, now, that's something you need to inform Laravel explicitly.

    Go ahead and look at the contents of the config/app.php file. You'll find an array entry that lists all the service providers that your app can use.

    'providers' => [

    /*
     * Laravel Framework Service Providers...
     */
    Illuminate\Auth\AuthServiceProvider::class,
    Illuminate\Broadcasting\BroadcastServiceProvider::class,
    Illuminate\Bus\BusServiceProvider::class,
    Illuminate\Cache\CacheServiceProvider::class,
    Illuminate\Foundation\Providers\ConsoleSupportServiceProvider::class,
    Illuminate\Cookie\CookieServiceProvider::class,
    Illuminate\Database\DatabaseServiceProvider::class,
    Illuminate\Encryption\EncryptionServiceProvider::class,
    Illuminate\Filesystem\FilesystemServiceProvider::class,
    Illuminate\Foundation\Providers\FoundationServiceProvider::class,
    Illuminate\Hashing\HashServiceProvider::class,
    Illuminate\Mail\MailServiceProvider::class,
    Illuminate\Notifications\NotificationServiceProvider::class,
    Illuminate\Pagination\PaginationServiceProvider::class,
    Illuminate\Pipeline\PipelineServiceProvider::class,
    Illuminate\Queue\QueueServiceProvider::class,
    Illuminate\Redis\RedisServiceProvider::class,
    Illuminate\Auth\Passwords\PasswordResetServiceProvider::class,
    Illuminate\Session\SessionServiceProvider::class,
    Illuminate\Translation\TranslationServiceProvider::class,
    Illuminate\Validation\ValidationServiceProvider::class,
    Illuminate\View\ViewServiceProvider::class,

    /*
     * Package Service Providers...
     */

    /*
     * Application Service Providers...
     */
    App\Providers\AppServiceProvider::class,
    App\Providers\AuthServiceProvider::class,
    // App\Providers\BroadcastServiceProvider::class,
    App\Providers\EventServiceProvider::class,
    App\Providers\RouteServiceProvider::class,

],

    From the next section onwards, we'll focus on the service provider, which is the main topic of this article!

    What Is a Service Provider?

    If the service container is something that allows you to define bindings and inject dependencies, then the service provider is the place where these dependencies are defined.

    Let's have a quick look at one of the core service providers to understand what it does. Go ahead and open the vender/laravel/framework/src/Illuminate/Cache/CacheServiceProvider.php file.

    <?php

namespace Illuminate\Cache;

use Illuminate\Contracts\Support\DeferrableProvider;
use Illuminate\Support\ServiceProvider;
use Symfony\Component\Cache\Adapter\Psr16Adapter;

class CacheServiceProvider extends ServiceProvider implements DeferrableProvider
{
    /**
     * Register the service provider.
     *
     * @return void
     */
    public function register()
    {
        $this->app->singleton('cache', function ($app) {
            return new CacheManager($app);
        });

        $this->app->singleton('cache.store', function ($app) {
            return $app['cache']->driver();
        });

        $this->app->singleton('cache.psr6', function ($app) {
            return new Psr16Adapter($app['cache.store']);
        });

        $this->app->singleton('memcached.connector', function () {
            return new MemcachedConnector;
        });
    }

    /**
     * Get the services provided by the provider.
     *
     * @return array
     */
    public function provides()
    {
        return [
            'cache', 'cache.store', 'cache.psr6', 'memcached.connector',
        ];
    }
}

    The important thing to note here is the register method, which allows you to define service container bindings. As you can see, there are four bindings for the cache, cache.store, cache.psr6, and memcached.connector services.

    Basically, we're informing Laravel that whenever there's a need to resolve a cache entry, it should return the instance of CacheManager. So we're just adding a kind of mapping in the service container that can be accessed via $this->app.

    This is the proper way to add any service to a Laravel service container. That also allows you to realize the bigger picture of how Laravel goes through the register method of all service providers and populates the service container! And as we've mentioned earlier, it picks up the list of service providers from the config/app.php file.

    And that's the story of the service provider. In the next section, we'll discuss how to create a custom service provider so that you can register your custom services into the Laravel service container.

    1. Create a Custom Service Provider

    Laravel already comes with a hands-on command-line utility tool, artisan, which allows you to create template code so that you don't have to create it from scratch. Go ahead and move to the command line and run the following command in your application root to create a custom service provider.

    $php artisan make:provider EnvatoCustomServiceProvider
Provider created successfully.

    And that should create the file EnvatoCustomServiceProvider.php under the app/Providers directory. Open the file to see what it holds.

    <?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;

class EnvatoCustomServiceProvider extends ServiceProvider
{
    /**
     * Register services.
     *
     * @return void
     */
    public function register()
    {
        //
    }

    /**
     * Bootstrap services.
     *
     * @return void
     */
    public function boot()
    {
        //
    }
}

    As we discussed earlier, there are two methods, register and boot, that you'll be dealing with most of the time when you work with your custom service provider.

    The register method is the place where you define all your custom service container bindings. On the other hand, the boot method is the place where you can consume already registered services via the register method. In the last segment of this article, we'll discuss these two methods in detail as we'll go through some practical use cases to understand the usage of both methods.

    2. Register Your Custom Service Provider

    So you've created your custom service provider. That's great! Next, you need to inform Laravel about your custom service provider so that it can load it along with other service providers during bootstrapping.

    To register your service provider, you just need to add an entry to the array of service providers in the config/app.php file. Add the following line to the providers array:

        App\Providers\EnvatoCustomServiceProvider::class,

    And that's it—you've registered your service provider with Laravel! But the service provider we've created is almost a blank template and is of no use at the moment. In the next section, we'll go through a couple of practical examples to see what you could do with the register and boot methods.

    3. Create the register and boot Methods

    To start with, we'll go through the register method to understand how you could actually use it. Open the service provider file app/Providers/EnvatoCustomServiceProvider.php that was created earlier, and replace the existing code with the following.

    <?php
namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use App\Library\Services\DemoOne;

class EnvatoCustomServiceProvider extends ServiceProvider
{
    public function boot()
    {
    }

    public function register()
    {
        $this->app->bind('App\Library\Services\DemoOne', function ($app) {
          return new DemoOne();
        });
    }
}

    There are two important things to note here:

    • We've imported App\Library\Services\DemoOne so that we can use it. The DemoOne class isn't created yet, but we'll do that in a moment.
    • In the register method, we've used the bind method of the service container to add our service container binding. So, whenever the App\Library\Services\DemoOne dependency needs to be resolved, it'll call the closure function, and it instantiates and returns the App\Library\Services\DemoOne object.

    So you just need to create the app/Library/Services/DemoOne.php file for this to work.

    <?php
namespace App\Library\Services;

class DemoOne
{
    public function doSomethingUseful()
    {
      return 'Output from DemoOne';
    }
}

    And here's the code somewhere in your controller where the dependency will be injected.

    <?php
namespace App\Http\Controllers;

use App\Http\Controllers\Controller;
use App\Library\Services\DemoOne;

class TestController extends Controller
{
    public function index(DemoOne $customServiceInstance)
    {
        echo $customServiceInstance->doSomethingUseful();
    }
}

    That's a very simple example of binding a class. In fact, in the above example, there's no need to create a service provider and implement the register method as we did, since Laravel can automatically resolve it using reflection.

    A very important note from the Laravel documentation:

    There is no need to bind classes into the container if they do not depend on any interfaces. The container does not need to be instructed on how to build these objects, since it can automatically resolve these objects using reflection.

    On the other hand, it would have been really useful if you had bound an interface to a certain implementation. In the next section, we'll go through an example to understand it.

    A Real-World Example of How to Use Service Providers

    Let's assume that you want to build a service which allows you to authenticate users in various ways. To start with, you would like to implement two adapters, JSON and XML, so that one could pass the credentials in the corresponding format to authenticate against your system. And later on, you can plug in more adapters for different formats as needed.

    It's the perfect example of implementing a Laravel service provider, since it allows you to implement multiple adapters for your service, and later on you can easily switch between different adapters.

    To start with, let's create a very simple interface at app/Library/Services/Contracts/AuthenticationServiceInterface.php.

    <?php
// app/Library/Services/Contracts/AuthenticationServiceInterface.php
namespace App\Library\Services\Contracts;

Interface AuthenticationServiceInterface
{
    public function authenticate($credentials);
}

    Next, let's create two concrete implementations of this interface. Basically, we just need to create two classes that extend the AuthenticationServiceInterface interface.

    Create the XmlAuthentication class in app/Library/Services/XmlAuthentication.php.

    <?php
// app/Library/Services/XmlAuthentication.php
namespace App\Library\Services;

use App\Library\Services\Contracts\AuthenticationServiceInterface;

class XmlAuthentication implements AuthenticationServiceInterface
{
    public function authenticate($xmlData)
    {
      // parse the incoming XML data in the $xmlData and authenticate with your db...happens here
      return 'XML based Authentication';
    }
}

    Similarly, the JsonAuthentication class goes in app/Library/Services/JsonAuthentication.php.

    <?php
// app/Library/Services/JsonAuthentication.php
namespace App\Library\Services;

use App\Library\Services\Contracts\AuthenticationServiceInterface;

class JsonAuthentication implements AuthenticationServiceInterface
{
    public function authenticate($JsonData)
    {
      // parse the incoming JSON data in the $JsonData and authenticate with your db...happens here
      return 'JSON based Authentication';
    }
}

    Now, instead of binding a class, we'll bind an interface. Revisit the EnvatoCustomServiceProvider.php file and change the code as shown below.

    <?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use App\Library\Services\JsonAuthentication;

class EnvatoCustomServiceProvider extends ServiceProvider
{
    /**
     * Register services.
     *
     * @return void
     */
    public function register()
    {
        $this->app->bind('App\Library\Services\Contracts\AuthenticationServiceInterface', function ($app) {
          return new JsonAuthentication();
        });
    }

    /**
     * Bootstrap services.
     *
     * @return void
     */
    public function boot()
    {
        //
    }
}

    In this case, we've bound the App\Library\Services\Contracts\AuthenticationServiceInterface interface to the JsonAuthentication implementation. Hence, whenever the App\Library\Services\Contracts\AuthenticationServiceInterface dependency needs to be resolved, it instantiates and returns the App\Library\Services\JsonAuthentication object. Now it makes more sense, doesn't it?

    Let's quickly revise the controller code as well.

    <?php
namespace App\Http\Controllers;

use App\Http\Controllers\Controller;
use App\Library\Services\Contracts\AuthenticationServiceInterface;

class AuthenticateController extends Controller
{
    public function index(AuthenticationServiceInterface $authenticationServiceInstance)
    {
        // Initialize $credentials by fetching it from the Request object here...
        echo $authenticationServiceInstance->authenticate($credentials);
    }
}

    As you may have guessed, the $authenticationServiceInterface variable should be the instance of App\Library\Services\JsonAuthentication!

    Before you test the above implementation, make sure to clear caches with the following commands.

    php artisan cache:clear
php artisan config:clear
php artisan clear-compiled

    Now, when you run the https://your-laravel-url/authenticate/index URL, it should print the JSON based Authentication message.

    The beauty of this approach is that you can swap the JsonAuthentication implementation with the other one easily. Let's say you want to use the XmlAuthentication implementation instead of JsonAuthentication. In that case, you just need to make the following changes in the service provider EnvatoCustomServiceProvider.php file.

    Find the following line:

    use App\Library\Services\JsonAuthentication;

    And replace it with:

    use App\Library\Services\XmlAuthentication;

    Similarly, find this one:

    return new JsonAuthentication();

    That should be replaced by:

    return new XmlAuthentication();

    You can use the same approach if you want to replace any core implementation with your own. And it's not only the bind method you could use for your service container bindings; the Laravel service container provides various ways of binding into the service container. Please check the official Laravel documentation for the complete reference.

    Implement the boot Method

    The next candidate is the boot method, which you could use to extend the core Laravel functionality. In this method, you could access all the services that were registered using the register method of the service provider. In most cases, you want to register your event listeners in this method, which will be triggered when something happens.

    Let's have a look at a couple of examples that require the boot method implementation.

    Say you want to add your own custom form field validator to Laravel.

    public function boot()
{
    Validator::extend('my_custom_validator', function ($attribute, $value, $parameters, $validator) {
        // validation logic goes here...
    });
}

    If you want to register a view composer, it's the perfect place to do that! In fact, the boot method is frequently used to add view composers!

    public function boot()
{
    View::composer(
        'demo', 'App\Http\ViewComposers\DemoComposer'
    );
}

    Of course, you want to import a facade Illuminate\Support\Facades\View in your service provider first.

    In the same vein, you could share the data across multiple views as well.

    public function boot()
{
    View::share('key', 'value');
}

    You can also use boot to define explicit model bindings.

    public function boot()
{
    parent::boot();

    Route::model('user', App\User::class);
}

    These are just a few examples to demonstrate the uses of the boot method. The more you get into Laravel, the more reasons you'll find to implement it!

    Conclusion

    In this article, we started with a look at the service container. Then we looked at service providers and how they are connected with the service container.

    Following that, we developed a custom service provider, and in the latter half of the article we went through a couple of practical examples.

    Photo

    martijn broeders

    founder/ strategic creative bij shineyrock web design & consultancy
    e-mail: .(JavaScript must be enabled to view this email address)
    telefoon: 434 210 0245
    7
    Plaats reactie...
    4elements
    Comments

Per - categorie

Op - datum

Copyright © 1999 - 2026 Shineyrock web design en consultancy, Alle rechten voorbehouden / Algemene voorwaarden / Sitemap: XML, HTML, Images, Mobile, News