We can just new an object up by ourselves. collect() - This creates a new instance of the Collection class.app() - huh? We don’t need this method.app_path() - why? If you need the path of the app, ask the app object.Here’s a list of three helper methods that we have but don’t need since there are better alternatives: It rarely leads to conflicts, but avoiding that altogether should be preferred. You just have to know that you sacrifice your independence for that handiness and your global namespace gets polluted. They seem very handy and yes, they are handy.
Laravel comes with quite a few global helper functions. It holds the data from your database, which is what models usually do, but it also has filtering logic, maybe sorting and even more in it. When you use Eloquent, your models have multiple responsibilities. In case you are not familiar with that, SOLID is an acronym that stands for: In addition, when putting such methods on your model, you are violating the S of SOLID. It makes refactoring harder, might confuse new developers, and static analysis gets harder as well. This is not only something that your IDE doesn’t understand. Those methods forward the call to a query builder. But since Laravel defines a _call() and _callStatic() method, it gets handled through them. You’re calling a static method popular() that nobody ever defined. I’ll explain that after you see how you usually call those scopes: It has nothing to do with the model object itself. That would mean that this method operates on a specific object of the class. If you call this method, it scopes the underlying SQL query by adding the given WHERE clause. For Laravel users, it’s pretty clear what it does. And you get no chance to name your properties differently from your columns. Of course, your IDE does not understand that without help. Everything is injected “magically” into the class by reading the table metadata. This seems irrelevant but for me, it makes quite a difference. The first thing you see is that there are no properties on the model. Sounds like good intentions, but I started to dislike this more and more. To do that, it lets the developer stuff a lot into the model that doesn’t belong there. This is partly due to the Active Record ORM pattern that’s being used and partly due to the fact that Eloquent wants to save the developer from having to write more code. But its design makes your application needlessly complex and prevents the IDE from correctly analyzing your code. It’s the ORM that’s shipped with a default installation. If you’ve already worked with Laravel, you surely know about Eloquent. It’s also partly due to PHP not being very well designed. I’m not even saying it’s only Laravel’s fault. Or, let me rephrase it: the better other tools will do the job. They generate classes, scaffolding for authentication and much more.īut the deeper you go and the bigger the projects become, the more complicated the development with Laravel will get. The console commands support you in every aspect during coding. It provides so many useful tools out of the box. I always enjoyed how easy it was to spin up an application and get going in minutes. I’ve worked with Laravel for about 2 years now. Photo by Kristopher Roller on Unsplash Intro But it is important to look closer and to make sure you know what you are using and why you are using it. I have no intention to convert people away from Laravel to other frameworks or languages. And when you stick with Laravel after reassessing, that’s fine. I’ll give you my thoughts and try to get you to rethink your framework choices as well. I am not trying to rant about Laravel or why other frameworks might be better. And I’ll tell you why!įirst of all, I want to make sure that you know about my intentions. It is time for a change in the tools that I use.
By Niklas Schöllhorn Moving away from magic - or: why I don’t want to use Laravel anymore