Декомпозиция Form Request в Laravel

Всем привет, сегодня я расскажу как и зачем я структурировал валидацию в Laravel.

Вспомним как работает Form Request

Form Request — это класс где мы описываем правила валидации для входящих данных. Обычно класс содержит набор правил под запрос из клиента. Мы можем его декларировать в контроллере, и через контейнер в Laravel он автоматически проверит данные на соответствии нашим правилам и через внутренние механизмы фреймворка выдаст ответ клиенту.

Для примера нам надо обновить профиль пользователя. Form Request может выглядеть вот так:

namespace App\Http\Requests;  use Illuminate\Foundation\Http\FormRequest;  class UpdateUserProfile extends FormRequest { 	public function rules(): array   {    return [ 		'email' => ['required', 'email'], 		'name'  => ['required', 'alpha'], 		'age'   => ['integer', 'max:120'], 	 ];   } 	 	public function messages():array 	{ 		return [ 		 'email.required' => 'Email необходимо заполнить email' 		]; 	} }

Выглядит знакомо и ничего не обычного. Схематично я нарисовал ниже как это выглядит. Все правила в одном Form Request являются неразделимыми и вроде это как не должно быть проблемой…

Но, давай-те представим, что мы разрабатываем телеграм бота и функция обновления пользователя необходима и здесь. Взаимодействия пользователя через бота несколько отличается от привычного взаимодействия пользователя на сайте.

Бот задает последовательные вопросы, в момент получает ответы и сразу должен их провалидировать. Будет странно — если в конце бот сообщит «еmail был не верный». В моем представлении бот ведет диалог, вопрос за вопросом, контролируя верность введенных данных.

Как Form Request решит эту проблему?

Итак у нас уже есть один Form Request который валидирует обычную форму из сайта.

• Мы можем постараться изменить наш Form Request под нашу задачу. Добавить необязательные правила(но это шанс из формы не отправлять все данные). Еще мне не нравится этот подход, так как он двухсмысленнен и нечитаем. Вне контекста мы(или коллега) позже не вспомним что валидируется и при каком случае.

• Добавить обычную валидацию. Тут есть нарушение принципа «Don’t repeat yourself». Если у нас добавиться новое правило(а оно обязательно будет), то нам надо не забыть его изменить уже в двух местах.

public function store(Request $request) { 	$validated = $request->validate([ 		'email' => ['required', 'email']   ]); }

Декомпозиция правил валидации

Мне в голову пришла другая идея, рассматривать каждое поле(field) как отдельное ValidatorValue.

Начнем с того как будет выглядеть наш предыдущий Form Request.

class UpdateUserProfile extends FormRequestDecompose { 	public function rules(): array   {    return [ 		new UserEmail(auth()->user()->id), 		new UserName(), 		new UserAge(), 	 ];   } }

• Мы отнаследовались от моего базового класса FormRequestDecompose, который содержит в себе некую логику по обработки объектов ValidatorValue.

• В список правил, мы добавляем теперь просто объекты.

• Этот способ не исключает обычное использование ключ и список правил в виде массива(для примера)

Как это работает?

Каждый класс реализует интерфейс ValidatorValue. В конструктор передаются внешние данные на которые мы можем опираться во время валидации. Еще в конструктор я передаю атрибут, если он может изменяться, но это зависит уже кода. В методе getRules описывается набор правил валидации, соответственно в методе getMessages кастомизированные ответы на эти правила(если они имеются).

class UserEmail implements ValidatorValue { 	private $attribute; 	 	private $exceptUserId;      public function __construct(int $userId, string $attribute = 'email') 	{ 		$this->exceptUserId = $userId; 		$this->attribute = $attribute; 	}  	public function getAttribute(): string 	{ 		return $this->attribute; 	} 	 	    public function getRules(): array     {         return [             'required',             'email',             "unique:users,email,{$this->exceptUserId}",         ];     }      public function getMessages(): array     {         return [             "{$this->attribute}.email"         => 'Пожалуйста, укажите корректный email',             "{$this->attribute}.required"      => 'Пожалуйста, укажите email',             "{$this->attribute}.unique"        => 'Email уже зарегестрирован'         ];     } }

interface ValidatorValue {     /**      * Should return list rules      * @example ['required','email','unique:users,email'];      * @return array      */     public function getRules(): array;      /**      * @return string      */     public function getAttribute(): string;      /**      * @return array      */     public function getMessages(): array; }

Как теперь мы можем решить нашу проблему с валидацией данных от бота?

В Laravel я использую BotMan, это фреймворк для работы с ботами и заточенный под Laravel.
Итак, в моем случае использую Facade для валидации. Все нужные данные и конфигурации мы передаем из нашего объекта.

$validatorUserEmail = UserEmail(auth()->user()->id);  $this->validator = Validator::make([ 		$validatorUserEmail->getAttribute() => $answerFromUser ],[ 	$validatorUserEmail->getAttribute() => $validatorUserEmail->getRules() ], 	$validatorUserEmail->getMessages()); if ($this->validator->fails() === false) { 		// ... }

К сожалению, это не тот клиентский код о котором мы мечтали.
Но мы можем написать небольшую обертку и выглядеть это будет более изящно:

if ($this->validate($answer->getText(), new UserEmail($this->user->id)) {    // ... }

Стоит упомянуть, что как и во фреймворке, я предварительно регистрирую в контейнере FormRequestDecompose, для его корректной работы.

В этом подходе мне нравится, что все правила находятся в одном месте. Мы можем его использовать как в Form Request так и при обычной валидации. Во-вторых название класса может быть более выразительным для предметной области, например: ConsumerEmail, SellerPersonalPhone.

Специально для ленивых и любознательных я создал репозиторий. Код там довольно простой, поэтому можно просто адаптировать его под себя. Если вы сталкивались в своей практике с похожей проблемой, напишите в комментариях как ее решали.