The best thing about #Laravel so far is the absence of #XML and #YAML files. All configuration I've seen so far is happening in #PHP files using fluent interfaces.
@danrot I use #Symfony & the #YAML config totally bothers me. I switch to the #php style whenever possible but it makes sample code hard to find because it's not the default. 😓
@syntaxseed Totally agree. I know they made some progress in that regard, and I would also always use the #PHP configuration.
But all summed up I would still prefer Symfony for now by a lot. Additionally to all that magic stuff that breaks IDEs it also has eloquent, which doesn't allow for a cleanly separated domain model.
The worst thing about #Laravel so far is the heavy usage of static and magic methods. Already took me quite some time to find a test failing only when all tests are run, which was caused by caching something on a static variable (not in #Laravel though). And for IDEs to work correctly multiple _ide_helper files are necessary, and even then it is not always working.
@Crell out of curiosity: did you already work on many #Laravel projects? I think the biggest problem is eloquent, but I am trying to go open-minded into this 🙈
@danrot I inherited a half dozen Laravel projects at $dayjob last year, and we've been working to update them. I went in knowing its reputation but trying to be open minded. I regularly find things I hate, but facades and Eloquent are at the top of the list.
Eloquent isn't an ORM. It's a bad query builder wrapped into static classes, because we're still in PHP 4 land.
@Crell I was already thinking if #Laravel would be nicer to use if you just would not use eloquent, but from the documentation pages I've read until now I've got the feeling that it is so deeply integrated that it might be hard to do so.
@Crell do you have a mastodon-sized take on facades? Most anti-facade sentiment I see is from (often junior) devs who are so excited about SOLID that they can’t wait to tell you about how any specific thing doesn’t meet their understanding of those principles. But I know you’re obviously not in that camp. Are you opposed to service location in general, or something about facades, in particular?
They're often named the same as the class they front for, which makes using both in the same file harder. (Need to alias one or the other.) This is especially an issue for, say, Request.
@Crell@chris Personally there are a bunch of things I dislike about Laravel, although I really liked it in the beginning but these days.. I mostly dislike that Symfony tries to have the same features, or equivalents that are close in functionality but in the Symfony way :)
I think once you’re used to how facades work, stepping thru them quickly isn’t that hard, but it’s annoying. And IDE support is mostly solved with docblock annotations, but it would be nice if that wasn’t necessary. The naming issue sucks.
As for 1, I would counter that it depends :) In most library-type code, accepting dependencies in the constructor is obviously better.
@chris I could see an "It Depends" argument pre-8.0. With CPP now, just listing your dependent services is so amazingly easy, and self-documenting, that there's no excuse to do anything less. (Assuming you have an autowiring container, which these days is all of them.)
@Crell I think http controllers are different. I just peeked at our codebase and nearly all facade usage happens in controller actions. IMHO calling a facade in update rather than adding a constructor, adding the promoted argument, then going back to the update method and calling $this-> makes the dependency LESS obvious.
Maybe it’s that there’s certain code that will never make sense outside of the fully-booted-app context, and I think the trade-offs are different in that code.
That said, at this point I'm of the mind that "big controllers" with a half dozen or more actions on them are a bad design choice anyway. Single-__invoke() controllers are just... nice. (And then listing your dependencies is trivial; you may not even need to scroll.)
@Crell yeah, I don’t mind the occasional big controller, but I think they’re often a smell. But even a pretty focused RESTful controller benefits from a facade here or there, imho.
And if things get out of hand, any code that I pull out into dedicated classes are going to use DI rather than SL.
Only outlier is auth, where relying on a globally-available “current user” is sometimes so much nicer than injecting the guard and fetching the user each time. Even if it bites you once in a while 🤷♂️
@danrot@Crell Thats true as Eloquent follows the ActiveRecord pattern. From my experience creating framework agnostic domain models is an academic exercise without any relevance in daily business. I never had a customer request to use their framework agnostic domain models of framework A and insert it in framework B.
@Konafets@danrot It's more that it makes testing harder. Framework agnostic code isn't (usually) about migrating frameworks, it's about keeping your components loosely coupled and so easy to test and modify.
Everything is static methods, which means you need custom, proprietary global variable hacks to test anything.
Mocking a data object is hard to impossible.
The list of properties/types of an object does not exist in code, so even knowing what the fields are (either you or SA tools) is impossible without examining the DB.
@Konafets@danrot Laravel is a throwback to PHP 4 era frameworks. It's three PHP 4 functions in a trenchcoat, not a modern OOP framework.
It clearly works for some people, but I find it horrible and will steer people toward better options whenever I can. It teaches all the wrong things to do in PHP.
@Konafets@danrot Both Symfony and Slim do a much better job of supporting modern good practices. I have my issues with both of them as well, but nothing as fundamental as Laravel's flaws.
I haven't used Laminas recently enough to have an opinion.
@Konafets@Crell Currently regularly facing another problem with eloquent models: They are a nightmare to debug. Instead of just seeing an objetct with its properties I have to go and find the attributes property amongst many others, which makes debugging unnecessarily hard...
@Konafets@Crell Sounds to me like you are working for an agency or something similar. IMO it makes sense to separate your business logic from your framework if you are building a long-living product like a SaaS. I've seen cases where none of the business logic could be reused when moving from an abandoned framework, because it was so tightly coupled and the replacement works differently.
Yeah, in theory it makes sense but in real world the landscape of ORM in frameworks is scattered. Symfony uses DataMapper (DM), Laravel ActiveRecord (AR), CakePHP a mixture of both, TYPO3 some sort of DM, CodeIgniter uses AR, Yii uses AR. So now tell me to which framework you want to migrate?
@danrot@Konafets@Crell you ccould map from the eloquent models to your entities though. and keep the eloquent models a convenience for the repository implementation
@thgs@danrot@Konafets "Pure functional languages have this advantage: all flow of data is made explicit. And this disadvantage: sometimes it is painfully explicit." --Phil Wadler
@thgs@Crell@Konafets In #Symfony there is no pollution of static classes and I don't know what you mean by pollution of persistent collection. And I currently cannot see how #Laravel helps with any of these pollutions, the way I see it, it even embraces them.
Yes, sorry to confuse. I was referring to Crell's comment about a proper data mapper ORM. Laravel does pollute with static classes you are right. The other mentioned pollutions come from other ORMs.
I believe we are all in the same page about the pollution.
Another thing I am really missing in #Laravel: Something like the #Symfony profiler. Getting information like which queries are executed or which events are dispatched always seem to need some code being manually added. IMO a framework should log this information somewhere by default if it is run in the development environment.
Add comment