Мне кажется, что вопросы валидации также структурированы по уровням, таким как презентация, бизнес и база данных.
Названия слоев ничего не значат для правил валидации. (Это означает только то, что это слои, где проверяются правила валидации.)
Вы можете заметить важную вещь, я в основном разрабатываю веб-приложения, и эти «правила» предназначены для таких приложений, но не для других вещей, таких как пакетные задания
давайте перейдем снизу вверх:
Правила проверки уровня базы данных.
В основном это «не нуль» (для полей и отношений). На этом уровне существуют все ограничения валидации (и они применяются базой данных), которые необходимы для самой реализации. Это означает, что в случае нарушения проверки происходит сбой приложения. (это не означает, что Business Logic может вычислить что-то неправильно, это действительно означает, что приложение возвращает не (полезный) результат вообще). В правилах проверки уровня базы данных важно понимать, что нарушение правил в этом слое означает ошибку. Таким образом, цель этих правил не в том, чтобы проверять, а в том, чтобы убедиться, что никакое критическое нарушение валидации не может быть сохранено, и чтобы приложение не зависало при каждой загрузке записи базы данных! - Таким образом, нарушение этих ограничений напрямую приведет к неразрешенному исключению. Потому что причиной является ошибка, и невозможно исправить неправильную запись в базе данных.
Проверка бизнес-уровня
Эти правила проверки существуют на бизнес-уровне, в основном в сервисных функциях. Что-то вроде «имя пользователя должно быть уникальным». Нарушение этих правил не приведет к сбою самой программы, но может привести к неверным бизнес-результатам. Вторым важным моментом является то, что правила проверки бизнес-уровня также могут применяться в базе данных. Но вместо неразрешенного исключения исключения нарушения должны кэшироваться и обрабатываться. А нарушения валидации бизнес-уровня - это не ошибки, а просто неверный ввод.
Проверка уровня представления
Эти правила проверки являются правилами, которые ничего не значат. В основном это глупые бизнес-правила, которые меняются каждый день и не влияют на результаты бизнеса. Это такие правила, как: «комментарий к вопросу о переполнении стека должен содержать не менее 10 символов».
Я проверяю эти правила только на уровне представления (конечно, на стороне сервера).
Конечно, ограничения бизнес-уровня или уровня базы данных должны быть (если это возможно без чрезмерной работы) проверены также во входных формах на уровне представления. Так, например, если есть поле, которое должно быть не нулевым, то это также нужно проверить в обработчике формы ввода на уровне представления.