Comments 9
Фреймворк — первый фильтр, который проверяет структуру запроса: типы данных, обязательные поля, базовые форматы (например, валидность email через регулярные выражения)
Только ка кто так получается, что, например email vasya+habr@mail.ru валидацию не проходит на большей части сайтов.
Например, нельзя создать заказ на дату из прошлого, даже если она технически корректна.
Заблуждение, можно создать заказ на дату из прошлого. Например забыли внести.
UNIQUE
как было бы здорово, если бы к этому волшебному, разработчикам сразу объясняли, что как минимум, where is_deleted=false (частичные индексы)
а также триггеры и хранимые процедуры
Только если вы ОЧЕНЬ хорошо понимаете, что делаете. В противном случае мы запросто получаем тонны говнокода.
Например,
CHECK (price > 0)на уровне БД гарантирует, что товар с отрицательной ценой не будет сохранен
Классно, правда, я люблю чеки, у меня на базе их сотни, но вы только что выстрелили в ногу образцам, подаркам и прочим акциям
Первый уровень валидации: защита на уровне фреймворка
И далее идет какое то издевательство. Эта статья для новичков? То что дальше происходит напоминает мне гайд по рисованию филина. Новичку очень хочется знать как взять фронтовый объект User и замапить его на class User со всеми красивыми фреймворковскими валидациями. Довольно любопытно, в питонистых статьях именно такие примеры встречаются очень часто, в пхпшных - почти никогда.
Ручной кастинг.
Извините, но дальше дичь пошла. "private const string FIELD_USER_ID = 'userId';"
Это вот было актуально лет эдак 20 назад, с тех пор у нас появилась возможность сделать типизированное свойство id класса User
Экранируйте специальные символы SQL/HTML (htmlspecialchars()).
Эта функция ничем вам не поможет удалять "специальные символы SQL". Кроме того, тут должно быть написано - НЕ ЗАНИМАЙТЕСЬ ЭТИМ - не получится.
Все, я сдаюсь, а после order->addLine($product) у меня глаз дергаться начал, потому что я понятия не имею какие линии у заказа и причем тут линии
Благодарю за детальный анализ и конструктивную критику.
Валидация email-адресов: Вы правы, что адреса вроде
vasya+habr@mail.ruявляются валидными согласно стандарту RFC 5322.Создание заказов на прошедшие даты: Согласен, что в некоторых бизнес-процессах может потребоваться создание заказов на прошедшие даты. В стате наведен просто пример, согласен что он не подойдет для всех случаев жизни.
Использование триггеров и хранимых процедур: Согласен, что применение триггеров и хранимых процедур требует осторожности и глубокого понимания.
Ограничения на уровне БД (например,
CHECK (price > 0)): Вы правильно подметили, что такие ограничения могут мешать реализации бизнес-логики, связанной с акциями или подарками.Согласен, что терминология должна быть чёткой и понятной. Использование термина "line" может быть неочевидным для некоторых читателей. Обновил статю и заменил на
addProduct, чтобы избежать недопонимания.
3. ORM — библиотеки вроде Doctrine или ActiveRecord ORM обеспечивают валидацию на уровне объектной модели. Они проверяют форматы данных, соответствие типов и бизнес-правила до выполнения запросов к БД. Например, валидация электронной почты по формату
Почему валидацию формата email нельзя сделать раньше? Кажется странно проверять формат в сущности БД
Почему нельзя? Можно и даже нужно!
Валидация данных, включая формат email, может и должна происходить на нескольких уровнях системы. На клиентской стороне (frontend) и в контроллерах (backend) часто осуществляется первичная проверка для быстрого отклика пользователю.
Но, Валидация на уровне моделей ORM играет свою роль — она обеспечивает дополнительную защиту и гарантирует, что данные соответствуют ожидаемому формату перед сохранением в базу данных. Это особенно важно в случаях, когда данные могут поступать из различных источников, минуя стандартные пути ввода. Таким образом, многоуровневая валидация повышает надёжность и безопасность приложения.
Это особенно важно в случаях, когда данные могут поступать из различных источников, минуя стандартные пути ввода
Данные не должны миновать стандартные пути ввода)
А вот дублирование проверок (по моему опыту) ни к чему хорошему не приводит. Сейчас звучит как 'Давайте сделаем проверки везде, непонятно как данные будут попадать сюда'.
Добавлю, что я про дублирование проверок на доменном слое и на БД объектах.
Каждый уровень системы отвечает за свою часть валидации:
Фронтенд: обеспечивает удобство для пользователя.
Бэкенд: гарантирует соблюдение бизнес-логики.
База данных: обеспечивает целостность данных.
Наличие валидации на каждом уровне позволяет системе адаптироваться к изменениям без риска нарушения целостности данных.
Таким образом, многоуровневая валидация — это не дублирование, а стратегический подход к обеспечению безопасности и надёжности приложения.
Один заголовок «Parse Not Validate» блистательного текста Лекси Кинг, которому уже больше пяти лет, — с лихвой заменит всю простыню выше.
Разбор уровней валидации