Where should i validate my request when there's controllers and services?

I have my request validation on services, and then my controller looks in this way.

    /**
     * Delete a company.
     *
     * @param Request $request
     *
     * @return \Illuminate\Http\JsonResponse
     */
    public function destroy(Request $request, int $companyId)
    {
        try {
            app(DestroyCompany::class)->execute([
                'account_id' => auth()->user()->id,
                'company_id' => $companyId,
            ]);
        } catch (Exception $e) {
            return $this->respondInvalid();
        }

        return $this->respondObjectDeleted($companyId);
    }

May i know which is good practice for validate request? Should i validate request in controller or service layer?

SilenceBringer

4 years ago

Level 55

@crazylife as for me, I prefer to perform validation in Form Request https://laravel.com/docs/8.x/validation#form-request-validation

This way it's isolated from Controller and Service. You have dedicated class to perform validation. Also it's reusable (use the same form request for store and update, for example)

Crazylife

4 years ago

Level 4

Yeah, i am using form request too. I am placing it in my service layer. Just wondering should it be placed in controller or service? Or just self preferences.

SilenceBringer

4 years ago

Level 55

controller is good place for form request, I think. No reason to call service at all if validation will fail (in case of validaton in service you still doing service call first, and then validation failes)

1 like

martinbean

4 years ago

Level 80

@crazylife You should be validating the data in whatever layer the input’s coming from. So in your case, the controller (ideally in a form request so your controller method is only invoked if the data is valid).

You should only be passing validated data to any service classes or models.

Your controllers shouldn’t be full of try/catch blocks either. Any domain exceptions you can catch in your exception handler and return an appropriate response. In your example, you’re just “black-holing” any exception thrown by catching it and returning a generic error response, so if an exception is thrown, you’re not going to know about it because it’ll never be logged. So a user’s going to say, “I got an error trying to delete a company” and you’re going to have no record of that error.

1 like