avatar

KONNECTWAY

Posted on Feb 17, 2025

Laravel’s Service Container Done Right

#PHP #Laravel #Service Container

 2 mins of reading

Laravel’s Service Container makes coding easier by automatically handling dependencies. Instead of manually creating objects and passing them around, Laravel does it for you. This helps keep your code clean, reusable, and easy to update.

In this article, we’ll look at how the Service Container works, why it’s useful, and some common mistakes developers make—like using the Factory Pattern when they don’t need to.

Service Container

The Service Container is a fundamental piece of what makes Laravel easy to code with. You could think of the Service Container as a delivery truck that has every tool you need.

The Laravel Service Container is essentially a central database of objects. It allows for objects to be re-used in different parts of your web app.

If you’re coding in Laravel, you will need to know how to work with the service container.

 

Dependency Injection

One of the great things of the service container is it allows for dependency injection, which you could think of as the delivery truck driver being able to read your mind and bring you everything you were thinking of.

When a method is called, the service container will automatically pass or “inject” the implementation as an argument.

Here’s an example of a class with a method we want to call:

 

Without dependency injection, we call doSomething this way:

With dependency injection, we can call the same method easier:

Although the second example has more code, the idea is that the binding is reused when another method is expecting the same type (reducing the amount of code overall). Another advantage is it makes the code more maintainable because if you want to switch to another implementation, all you have to do is update the binding in the service provider:

There are other things that you can do, such as adding singleton or scoped instances. More information is located in the Laravel documentation.

 

Factory Pattern

The service container also provides the factory pattern. The factory pattern allows you to specify how an object is created (using a callback):

Then we can get an instance of “SomeInterface” later on in the code:

 

Problem & Solution

The problem is when programmers reinvent the wheel by using the factory pattern to do what dependency injection would be doing already:

There’s a couple problems with the above:

  1. The abstract EncryptionAlgorithm doesn’t need to be bound to a factory callback. If the implementation for SettingRepository did change, that would make the factory binding irrelevant.
  2. The EloquentSettingRepository implementation is bound to SettingRepository so we should at least be using the service container to make SettingRepository.

Most importantly, this breaks dependency injection. There maybe a time when you would need to do this, but that would be very limited.

Instead, it’s best to let Laravel do it’s magic and build the object for us:

There’s no more factory for “EncryptionAlgorithm” because that’s the magic of Laravel. Work smarter, not harder!