Laravel dependency injection: A Practical Guide to Method Injection

When I started working with Laravel, I spent way too much time manually instantiating classes inside my controllers. I’d see new PaymentProcessor() inside a store method and think, "This is fine, it works." But then came the unit tests, and I realized I’d painted myself into a corner.

If you're tired of bloated controllers and brittle code, laravel dependency injection is the tool you need to master. Specifically, using laravel method injection allows you to type-hint dependencies directly in your controller actions. Laravel’s service container handles the rest, resolving those classes automatically before your code even runs.

Why move beyond constructor injection?

Most tutorials teach constructor injection. You inject a service into the class constructor, assign it to a private property, and use it across multiple methods. This is the gold standard for most cases, especially when a service is needed by every method in the controller.

However, sometimes you have a controller with five different methods, and one specific method needs a heavy service that nobody else cares about. Injecting that service into the constructor bloats the controller for every single request.

Here is where laravel method injection shines:

PHP
public function store(Request $request, StripePaymentService $paymentService)
{
    #6A9955">// The container resolves $paymentService only when this method is called
    return $paymentService->charge($request->amount);
}

It’s clean, it’s precise, and it keeps your controller's footprint small.

The journey to clean controllers

Early in my career, I tried to keep everything in the constructor. I ended up with controllers that had 10+ dependencies. My __construct method was longer than the actual business logic. I thought I was being "proper," but I was actually creating a maintenance nightmare.

When I refactored to use Laravel Service Container: A Beginner’s Guide to Dependency Injection, I realized that the container doesn't care where you ask for the dependency. It just needs to know how to build it. By moving specific dependencies directly into the method signature, I cut down on unnecessary overhead.

If you're still struggling with where to put your business logic, remember that you should designing a clean service layer in Laravel without over-abstraction to avoid turning your controllers into dumping grounds for code.

How Laravel method injection works

When a request hits your route, Laravel’s router identifies the controller and method. Before executing the method, the framework inspects the method signature using PHP's Reflection API.

1. It looks at the type-hinted classes.
2. It checks the laravel service container to see if it can resolve those classes.
3. It instantiates the classes (and their dependencies recursively).
4. It calls your method, passing in the resolved instances alongside the request data.

This happens in roughly 2-5ms for standard services, which is negligible for most web applications.

A common pitfall: The "God Controller"

A common mistake is injecting too many things into a single method. If you find yourself needing four or five services in one controller method, you aren't just using laravel dependency injection—you're hiding a design problem.

If a method needs that many dependencies, that method is likely doing too much. I usually stop at two injected services per method. If I need more, I create a dedicated Action class or a Service class that encapsulates that logic.

Frequently Asked Questions

Can I inject my own classes? Yes. As long as the class can be resolved by the container (i.e., it doesn't have required parameters the container can't guess), you can type-hint it in any controller method.

Does this work in Laravel 10 and 11? Absolutely. Method injection has been a core feature since the early days of Laravel 5. It’s rock-solid and unlikely to change.

Should I use this for everything? No. Use constructor injection for dependencies used across multiple methods. Use method injection for "one-off" dependencies that only one action needs.

Wrapping up

Using php dependency injection effectively is about balance. Don't over-engineer your controllers, but don't shy away from using the container to your advantage. Start by identifying one controller where you're instantiating a class manually and swap it for a type-hinted argument. You'll likely find that your tests become easier to write and your controller code starts to feel much lighter.

I still occasionally find myself reaching for new when I'm prototyping a feature quickly. Then I remember the headache of writing the unit test, and I refactor it back to injection. It’s a habit you have to build, but it pays off in the long run.