Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: