2015-02-27 3 views
3

Есть много споров о том, где валидация принадлежит к приложению Laravel. Особенно, когда все усложняется. Лично я считаю, что работа модели должна принимать только действительные данные и бросать исключения, когда она получает что-то недействительное.Laravel подход к комплексной валидации

Имея это в виду, я хотел бы предложить следующий сценарий для модели User (я работаю на что-то вроде этого в данный момент):

  • Пользователь имеет поля:
    • ID: Всегда требуется, числовое, автоинкрементное.
    • Пользователь: Всегда требуется, альфа-тире, уникально.
    • E-mail: Всегда требуется, адрес электронной почты, уникальный.
    • Пароль: Обязательно требуется> 6 символов. Hashed.
    • Изображение профиля: - Дополнительно, png/jpg/gif, < 10mb. Сохраняется в базе данных как имя файла, указывающее на изображение в файловой системе в определенном пользователем каталоге (контент/пользователи/USERID/PROFILEIMAGE). Загруженное изображение обрезается и изменяется до его перемещения в это место. Необходимо также определить доступное имя файла.

Есть множество вариантов, некоторые считают, что проще в реализации, но чувствовать себя неправильно:

Вариант 1: проверки контроллера. Придерживание проверки в контроллерах (контроллерах), которые обрабатывают этот объект, легко сделать. С другой стороны, правила повторяются повсюду, и это похоже на плохой путь.

Вариант 2: Валидаторы формы. Создание валидаторов разделителей для разных форм. По сути, это более или менее тот же подход, что и вариант 1, но мы только что извлекли валидацию для отдельных классов. Правила все еще повторяются в разных местах и ​​все еще чувствуют себя грязными.

Вариант 3: Полная проверка модели. Добавление правил проверки в модель и подтверждение перед сохранением (либо путем явного вызова метода проверки с контроллера, либо проверки на сохранение). Чувствует себя намного лучше, но все еще имеет недостатки из-за сложности сценария. Нам нужно будет иметь дело с исключением идентификаторов в уникальных правилах для существующих записей. Нам нужно будет обрабатывать хэширование паролей перед сохранением в базе данных (если бы мы загрузили запись из базы данных, модель будет содержать хешированный пароль, который действительно не следует проверять). Нам все равно придется иметь дело с обрезкой/изменением размера/перемещением загруженного изображения и созданием уникального имени файла.

Вариант 4: Функция проверки/обработки модели. Напишите функцию, которая принимает данные и проверяет их (выбрасывая исключения, если они недействительны) перед установкой атрибутов. Проверяет только данные, которые он предоставляет (мы можем, например, передавать только новый образ профиля). Динамически настраивает правила на основе того, существует ли объект или является новым объектом.Вызывает соответствующие функции обработки, например функцию, которая будет обрабатывать изменение размера/обрезку/перемещение загруженного изображения и удаление старого изображения профиля.

Вариант 5: Модельные мутаторы. Напишите мутаторы, которые отвечают за проверку и обработку полей, которые они представляют. Это гарантирует, что в модель могут попасть только достоверные данные, и вся обработка будет выполнена. Ошибки могут быть обработаны либо путем мгновенного выброса исключений, либо путем отслеживания проблем с использованием поля ошибок, которое затем можно было бы получить. Недостатками может быть то, что если поле не задано, то проверка этого поля никогда не вызывается, и поэтому некоторые пустые обязательные поля могут проскальзывать через сеть - я полагаю, это можно было бы устранить, убедившись в том, что в контроллере все входные данные проходят через ,

Вариант 6: Модельные мутаторы + Полная проверка модели. Модельные мутаторы, как ранее описано в варианте 5, с добавлением проверки всей модели перед сохранением данных, как в варианте 3. Это позволит убедиться, что пустые поля не проскальзывают через сеть.

Любые предложения?

Обратите внимание, что я не получаю никакой помощи по коду. Просто ищите предложения и рекомендации о том, как наилучшим образом выполнить сложный сценарий.

Приветствия

ответ

7

Laravel 5 обеспечивает Form Request Validation - что это отличный способ справиться проверки в настоящее время. Все правила хранятся в одном месте и следуют принципам DRY и SRP.

Они дают вам возможность содержать сложную проверку, но также выполняют простые запросы очень быстро.

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

+0

Спасибо за ваш ответ. К сожалению, на данный момент я использую 4.2, возможно, мне нужно обновиться до 5. Мне нужно будет глубже вникать в это. Как насчет обработки загруженного изображения и т. Д.? Скажем, у нас есть действительный запрос формы, и мы подключаемся к контроллеру, готовому к обработке. Сделаете ли вы это в своей модели, возможно, через мутатор (игнорируя всю проверку) или, может быть, он лучше подходит для контроллера? Может быть, его даже можно каким-то образом убрать. – Jonathon

+0

По ходу процесса я хочу удалить существующее изображение, переместить новые изображения в нужное место и обрезать/изменить его размер. – Jonathon

+0

Я бы справился с этим в команде «Laravel 5» сейчас - http://laravel.com/docs/5.0/bus. Итак, переходите к контроллеру (с проверкой формы), затем выполните команду контроллера, чтобы сохранить все. В самой команде я бы справился с сохранением образа, а модель сохранила как две проблемы для управления в рамках одной команды. – Laurence

Смежные вопросы