Laravel Facades came in for some criticism a couple of years ago.

https://www.reddit.com/r/PHP/comments/1zpm0y/laravel_lets_talk_about_facades/ http://paul-m-jones.com/archives/5952 https://www.brandonsavage.net/lets-talk-about-facades/

I’ve got a greenfield project at work using Lumen (Laravel Lite), which is what’s brought it back to my attention.

Lumen, by default, switches off the Facades feature.

However, a bunch of the documentation asks for you to uncomment the line $app->withFacades() to switch them back on.

Sadly, it doesn’t state the alternative. It’s as though the intention as that you’ll end up using them and you don’t have a choice. The way around it is to use the string you find in the facade accessor in a call to $app->make which you can do in a service locator. I’m not too keen on the service locator (anti-)pattern either but it does the job, keeps the link between config and instantiation in one place. (I’m open to alternatives, here.)

You’d think, if they were disabled by default, that the documentation would profer the alternative. It doesn’t. So what you’ll probably find as a result is a bunch of Lumen apps in the wild with facades enabled.

Ignoring the done-to-death situation about the naming issue referenced above, which is a valid concern, Facades create problems.

Laravel is hugely popular. It’s popular among experienced devs and juniors alike. I like it myself, I think Eloquent is hands down the best ORM out there. We’ve got a bunch of complex relations between entities in the aforementioned greenfield project and Eloquent makes it a breeze to handle them.

I like a lot of other aspects of Laravel too. The general concept of expressive APIs is a superb design decision. The vast array of validation options available. The way the artisan console commands take away some of the boilerplate you’d need if you were writing a bare Symfony console app. The scheduler, with its cron-style syntax hidden behind syntactic sugar.

The issue is when less experienced devs get their hands on Laravel. In particular, the Facades. Sadly, what you end up with is two things.

When Facades are used as is, you end up with hidden dependencies in the code. All of a sudden, a class depends on a Facade. It’s not been dependency injected. It’s not obvious the dependency is there; it’s buried in a method somewhere. It breaks the SOLID principles. Ultimately, it contributes to technical debt and developer headaches.

Secondly, when less experienced devs witness this kind of usage, it inevitably leads to the creation of tons and tons of static methods. Global state. Difficult to test and extend. That’s another topic that there’s plenty written about already. Suffice to say, Laravel Facades leads to their usage, because inexperienced devs see it as being OK to do.

http://stackoverflow.com/questions/7026507/why-are-static-variables-considered-evil http://stackoverflow.com/questions/752758/is-using-a-lot-of-static-methods-a-bad-thing