ООП дизайн - проверка, когда проверка означает попадание в базу данных для проверки

Question

Давайте представим, что мы говорим о HTML-форме жалобы, одним из полей которой является список продуктов из каталога компании.

Я понимаю, что проверка обычно (всегда?) Идет в своем собственном классе.

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

Но как насчет проверки, которая требует доступа к базе данных - например, проверка того, что продукт на самом деле является продуктом, который у нас есть (а не кто-то подделывает форму). Это можно сделать только путем поиска соответствия в базе данных ... но моя база данных абстрагируется от моего шлюза.

Добавлять ли логику проверки в мой шлюз? Я создаю классы шлюза валидатора? Наделить ли мой валидатор логикой базы данных?

РЕДАКТИРОВАТЬ - попытаться уточнить ...

1. клиент нажимает ссылку на форму жалобы
2. Форма жалобы HTML построена из выпадающего списка <select><item></item></select> с продуктами X из нашего вымышленного каталога компании
3. Клиент заполняет форму и отправляет // Wiseguy изменяет HTML, поэтому продукт представляет собой "Шведские шарики" и отправляет
4. Класс формы проверяет простые вещи, такие как дата, все необходимые поля имеют данные, адрес электронной почты и т. Д.

на шаге 4, чтобы проверить, является ли продукт, на который вы жалуетесь, законным, вам нужно нажать на таблицу продуктов базы данных, чтобы убедиться, что это все еще действительный пункт данных. Эта логика должна идти в классе формы, классе шлюза или где-то еще? если поместить его в форму класса, это порождает зависимости, не так ли?

Answer 1

Проверка, как ни странно, не должна выполняться напрямую через класс проверки. Класс объекта модели (в данном случае, вероятно, Complaint) должен включать в себя класс Validation, и проверки должны выполняться там. Поскольку жалоба имеет доступ ко всем жалобам, методы проверки могут использовать методы класса Complaint или, при необходимости, вызывать другой класс модели.

Когда вы говорите «шлюз» к базе данных, я полагаю, что вы говорите о Object Relational Mapping (ORM), который позволяет объектам модели, таким как Complaint, абстрактно взаимодействовать с базой данных. ORM не должен знать структуру или специфику приложения, он должен быть только абстрактным API для объектов, предназначенных для связи с базой данных или другим бэкэндом.

Конечно, мой ответ не охватывает всего, поэтому дальнейшие вопросы / разъяснения приветствуются.

Answer 2

Обычно рекомендуется хранить только достоверные данные. Таким образом, необходимо обязательно написать валидатор на стороне сервера, чтобы убедиться, что запросы действительны и в базу данных помещаются только действительные данные, а в качестве оптимизации обычно проверяются на стороне клиента (например, в JavaScript), чтобы пользователь был информирован неверного ввода без необходимости отправки формы и без необходимости совершения туда-обратно. Выполнение проверки как части записи в базу данных позволяет выполнять последующее чтение без всяких проверок.

Я не знаю специфики того, что для вас считается "действительным", но вы, вероятно, можете сохранить множество поисков в базе данных с помощью кэширования. Возможно, вы могли бы дать больше информации о ваших требованиях?