An Eloquent Story
Laravel has the stigma of being an ideal framework for starting out projects but not for enterprise level, I disagree with that. Laravel is well designed, has amazing abstractions, an excellent service container, a vibrant community and has a low learning curve. On top of all that, it’s a beautiful, elegant and modern framework. I just love using it and can’t get enough of it.
However as anything in life Laravel also has a dark side, it offers what I refer to as super-couplers in the bundle. Because these super-couplers are handy to use (and look cool), people just use them without thinking. And not thinking it’s the same as having no plan, no design. No design is worse than bad design, it prepares the terrain for the big rot and invites in many other software development boogie men to the party.
I’m referring to Facades and Eloquent, let’s see why I consider them super-couplers.
Facades
Laravel facades proudly present you the concept of doing anything, anywhere. Yay!! 🎉
But if it’s not your last day on earth, you should not be doing everything everywhere. And more, doing anything anywhere IS THE DEFINITION of the big ball of mud.
As alternative to facades Laravel offers contracts to those who spot the trap straight away. So please use contracts. Laravel contracts are interfaces of the framework’s core services. And remember that abstractions last longer than implementations, you can rely on those beautiful contracts, pass them around, but be disciplined about where to use them. As a rule of thumb you should only get the contracts in controllers, commands or in your own services. Question yourself before using them: would you log or access the session inside a model or view? Is it something you should be able to do just because you can?
Eloquent
Oh Eloquent, you’re so good yet so bad - what should I do with you? Why do I love you so much?
Follow any Laravel tutorial and Eloquent will be there, omnipresent. In routes, in views, being serialised on jobs, you name it… Follow what you see on Laravel documentation and you’ll have your application metastasised with Eloquent, it’s the Laravel super glue. Do it and YOU WON’T BE ABLE TO EVER CHANGE ANYTHING IN YOUR DATABASE. Remove or rename a field and you’ll see your application scream in pain.
It’s such an anti-pattern, you can basically couple every single layer of your application with the database, how much more wrong can it be? 🙉
Despite being too magic Eloquent is very handy and I don’t intend to stop using it, but it is like a lion cub in your house, before it grows and eats your family you’ll need to put it in a cage. Find a nice place to lock Eloquent up, I suggest using the repository pattern as a cage, only use Eloquent inside repositories, lock it there and throw the keys away.
A good way to use Eloquent models is to treat them as just a representation of a database row with the query builder in the backpack. Avoid adding logic to them, you can maybe add some static methods to help you with common queries and perhaps constants for common field values but don’t go any further than that. Leave them starving and anemic and you’ll have an excellent tool to help you work with your database.
Conclusion
Facades are a no no, avoid using them.
Eloquent is handy but very dangerous, it can prevent you from evolving your database schema, and not evolving it will couple your system to the past.
Take any framework documentation with a pinch of salt, their sole objective is to help people learn the framework.
But things are not black and white. After making my case against them, is there any other situation where I’d still use Facades and Eloquent? It may sound contraditory but my awnser is absolutely yes! I’d use them in a very small API for example, something I can easily refactor before it becomes a problem.
