Laravel without Facades Part 0: Intro
I like Laravel, I really do. But, I don’t like Facades, I just don’t.
In the following few posts I’ll try to explain ways of using Laravel without need of Facades.
I mean, Facades are OK for starters/learners, for smaller projects, or when you are in a hurry to make a deadline. But for mid/large size projects, when you are working in a team with other developers, Facades are not the best choice.
Why?
1. Facades behave like static classes
First of all, Facades behave like static classes and static classes are considered as bad practice (source 1 and source 2).
Static methods and variables result in the poorly designed codebase and they try to introduce procedural code into an object-oriented world. Static variables introduce global state and static methods break encapsulation.
Also, another problem with static classes is writing tests. Testing static class in isolation is very difficult.
Explanation from Laravel documentation:
Facades provide a “static ” interface to classes that are available in the application’s service container. Laravel facades serve as “static proxies” to underlying classes in the service container…
2. Bad code readability
Why is this important? Well, when working on a mid/large scale project with a few other team members, code readability is very important. If there are static classes (Facades) all over the place it’s just hard to read dependencies of some class or method.
3. No autocomplete option
In some IDEs (like NetBeans) there are no autocomplete option for Facades because they are “magically” loaded. Variables and methods are invisible to IDE.
I know that there are some packages like barryvdh/laravel-ide-helper, but if you need to install additional packages just for autocomplete option, well, that’s just wrong.
4. Harder to switch to other Frameworks
As far as I know, other PHP frameworks don’t use Facades or static classes. I haven’t found any mention of “facade” or “static” keyword in other frameworks documentation: Symfony, CakePHP, Phalcon, Zend, etc.
So, if you are making a switch from Laravel (with Facade usage) to any other PHP framework, it’s gonna be much harder then making a switch if you have already embraced code without Facades and static classes.
Conclusion
For me, Facades are bad practice and personally, I don’t like to work with them. I’m a big fan of PSR, because I like my code to be clean, self-explained, easy to extend, inject and use.
But, there are a few cases where Facades are “OK” to use (I use them as well) - in database migrations and seeders. It’s way easier and quicker this way, there is no need to inject anything and to waste time on something that will be run only once.
If you want to be even more consistent in your coding style, you can remove Facades from migrations and seeders too but maybe that could be just overhead.
Thanks everyone for reading this intro series showing you how to use Laravel without Facades. Next post will be about defining and using Router class and setting up the routes.
Not Convinced?
There are also some other articles on the Internet like this, who explain Laravel Facades and why not to use them: source 1, source 2, source 3.
Useful links
List of Facade class references on official Laravel page: https://laravel.com/docs/5.8/facades
P.S. global helper functions like app() and config() are also bad practice, they are just wrapped up Facades.
Next article: Part 1: Routing
