Three ways to get a dependency in Laravel

Same repository, three ways to get it in Laravel 5.

// 1. Constructor injection
public function __construct(OrderRepository $orders)
{
    $this->orders = $orders;
}

// 2. Facade
$order = Orders::find($id);

// 3. Service locator
$orders = App::make('App\Repositories\OrderRepository');

All three work. The container resolves everything either way. The difference is in what the class tells you about itself.

With constructor injection the dependencies are in the signature. You open the class, you read the constructor, you know what it needs. A test passes a mock and never touches the container.

The facade hides the dependency, but at least it is greppable and visible at the call site. In a controller I can live with it. Controllers are framework territory anyway.

App::make() deep inside domain code is the one I fight. It is a service locator. The class claims to need nothing and secretly needs everything. You learn its real dependencies at runtime, one exception at a time. And a test suddenly needs a bootstrapped container just to construct the object.

The rule I use: business code takes dependencies through the constructor, always. Facades are allowed in controllers and views. App::make() is allowed in exactly two places, service providers and factories, because building objects is their job.

And the smell test. If a constructor takes seven dependencies, injection did not fail you. The class does seven jobs. The container will happily hide that behind App::make(). Injection makes it hurt, and it should hurt.

I know the smell because it was mine. On a previous project I had App::make() in every second method of the billing code, because the constructor was getting long. The constructor was telling me something. I told it to be quiet.