Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@nitnip i do not think that laravel encourages repositories. the opposite. ORM make developers spread the queries everywhere. even queries with great logic. Model the same. God Objects.
But what i try to say is that even if i try to write good code, i have to open the documentation like a configuration. "how was the name of dates property on model, how was the casting, how was the other thing that takes all parameters at once and create the model".
ok you start to remember the basic. but... -
It's dependent on the project and it's size.
Many patterns only make sense with a reasonable project size and _badumts_ human resources.
DI is a necessity in my opinion, repository pattern, too - in a gist a domain driven approach.
What I dislike mostly are annotations and all the kind of magic methods that some framework are very fond of.
Especially gimmicks like "Autotransformation / serialization" which some devs love and sell as an great invention for automation, e.g. that an incoming request gets transformed with no additional call to an DTO like object.
Or the myriad of magic methods in PHP (__set, __get, ...) and their abusal.
Many devs dislike boilerplate code - till they had the joyful job to debug the automatic code.
Be it transformation errors (e.g. special values, float errors, datetime formats, milli -/ microsend timestamps, ...) or just a missing http header like Accept / Content-Encoding and suddenly and encryptic exception with a traceback of 10 k lines....which tells you what and why. But not the simple reason how - unless you sifted for hours through the traceback.
I think boiler plate code which is self explanatory is better then some magic deep nested vodoo fuckery that is slow, unprecise and in an error case an total enigma. -
@IntrusionCM you are the one that understood me. especially in this header application. oh god.
As a PHP Developer, *heavy breathing*
This SINGLE space just broke my entire project. Good luck debugging that one...
is laravel app really enjoyable to write ?
i started as a laravel dev. the known story , all code in controllers etc. As i started to improve, fortunately i changed company, and worked with a symfony project. A symfony that looked like java. hundreds of classes, tests, yaml injections , objects for requests, for everything.
I thought that i missed the old laravel days, and i took an extra job on laravel again. I was soooo wrong.
It was not only that the code of the previous dev was inferior to what i am now used, it is that i have to be with an open documentation all the time. Even if the project is in the same version that i have used to earlier (an old one).
You have to check all the time the model settings, the migration, the magic tricks of model mass insert, the castings, the validation rules, why the tests are not finding some routes, why this, why that, how it is written this.
Excuse me, but i think the fun and easiness is far from what they say and what i thought it was. I start to change my mind and believe that inserting the request to a simple php object is more controllable than the gandalf tricks that laravel is doing, and you cannot know if it is worth your time to test it . And more importantly, you do not have to look at the cookbook, all the time@@@
rant
laravel