I've worked in countless languages and used plenty of frameworks (and done a ton of PHP development) but I really don't understand Laravel.
You have to do a big dance of putting files in all right places and implementing all the right interfaces -- as you would with any framework -- but Laravel doesn't seem to give you anything for your trouble. Take, as one example, validation -- you still have to write virtually everything yourself! There are some very basic hooks and some wire but that's all. For all the trouble, I expect more actual features from my framework.
Putting files in the right places? You can technically put them anywhere you like, and just use proper namespacing.
For example laravel defaults to App/ for models.. so App\User which is ugly if you have 50 models. I ALWAYS use App\Models\User instead, so I move it to the App\Models folder, put all my other models there and presto, chango.
The opinionated flavour makes a lot more sense in a large team - I can pickup a Laravel App, and if it has followed convention, run composer install and be productive within a matter of minutes.
You don't have to do everything yourself, most things are abstracted and easily accessible.
It's a framework, it's job is to make it easy to structure the site and handle common tasks for you. Laravel does have validation built in. You might have to put custom rules to use every now or then, but I don't see a way around that.
But laravel sure has its cost when it comes to performance - it's not possible to have it both ways.
Laravel has a weird validation abstraction but you still have to do all the work. I'm used to being able to define my model have all my validation rules derived automatically (so I'm not repeating myself everywhere) and displayed automatically. Laravel just makes you learn a whole bunch of new conventions and functions but you still have to do it all yourself.
I don't see the value of:
validate('title' => 'required');
vs.
if (empty('title')) $errors[] = 'Title is required.'
Especially when this happens at the controller level.
To be fair, validation at the controller level is recommended only for simple cases. See form request validation [1] for more complex situations that require better code decoupling.
That being said... yes, the validation system is lacking. For instance, there's no built-in way to perform sanitization before validation, nor normalization afterwards. Definitely one of the parts that I like less about the framework.
That form request validation is such a strange level of abstraction. It makes far more sense to me to validate the model than to validate each individual HTTP request.
Why have a separate class/component that's highly tied to single controller or action? It just seems like dividing non-reusable logic up between files for no good reason.
In the 80% case you are totally right, and having automatic validation depending on the model would be easier. However, I would argue it is not a good fit for Laravel, and that in the 20% case it creates more problems than it solves.
It doesn't suit Laravel very well because it uses Eloquent and its Active Record approach to models. This means that the model already has way more responsibilities than it arguably should. Now you also want to make it responsible for validations...
In the 20% case, you may have different validation rules for different actions (you can PATCH an object with a subset of fields, or you can set a field during creation but not during update, or whatever you can think of (it happens at some point). Also, validation is oftentimes depending on the user's permission (this field can only be set by supervisors, or only administrators may set a price lower than XXX$, or... you get the point I hope.
Finally, you don't need to do anything to "validate each individual HTTP request" from the coding side. If all your actions that refer to the Thing model have the same validation rules, just create a ThingRequest object with the rules once and inject that as a parameter to your controller methods. Laravel automatically resolves that object, filling and validating it before giving it to you, as in:
class ThingController {
function store(ThingRequest $request) {
$thing = new Thing($request->validated());
$this->save();
flash()->success('Thing saved');
return redirect()->route('things');
}
}
And that's it, this includes validation (as defined in ThingRequest), with the possibility to add custom validation messages and all.
> In the 80% case you are totally right, and having automatic validation depending on the model would be easier.
That's my point! It seems to be a common refrain for Laravel. A good framework should make the 80% super easy -- that should be the trade off. For the last 20% you can do some easy manual validation in the controller -- hardly a big problem.
> This means that the model already has way more responsibilities than it arguably should.
Not a solid argument for Laravel...
> Now you also want to make it responsible for validations...
If I have a model validator that requires every basket to have at least 3 eggs of different colors then that validates the user-interface and can validate the command line process that adds a purple egg to every basket. With Laravel, validation is far too tied to web requests. And if you have multiple models that work together in different combinations in a controller you're creating different CombinationOfThingRequests to validate it.
> If all your actions that refer to the Thing model have the same validation rules, just create a ThingRequest object with the rules once and inject that as a parameter to your controller methods.
So you have a ThingRequest that exactly validates a ThingModel -- that's not very reuseable. How many different controllers exactly manipulate a ThingModel that the request is identical across them all? How many actions even do that? If this ThingRequest is responsible for validating more complex relationships, like the basket/egg example above, that means my HTTP request object is querying my database! If that's not the wrong level of abstraction, I don't know what is.
My opinion is that the most valid separation of concerns in MVC puts the application state in the model -- it's the thing that is valid or not valid.
I get that there are places where you need more specific validation and that can easily go in the controller.
What I can't imagine, and maybe you can help with this, is when you'd need to reuse validation across controllers that doesn't make sense the model?
I absolutely could not understand why Laravel divides things the way it does and I just did not like it. Request classes are a concept that don't even need to exist, and don't, in other frameworks.
You have to do a big dance of putting files in all right places and implementing all the right interfaces -- as you would with any framework -- but Laravel doesn't seem to give you anything for your trouble. Take, as one example, validation -- you still have to write virtually everything yourself! There are some very basic hooks and some wire but that's all. For all the trouble, I expect more actual features from my framework.