Каково обоснование реформы для того, чтобы не быть в моделях?

Question

Жемчужина реформы выступает за отсутствие валидации в моделях. Вместо этого он защищает их в форме.

Утверждения из моделей

...

Иногда, когда вы по-прежнему сохраняете проверки в своих моделях (чего не следует делать), копируя их в форму, может показаться неправильным. В этом случае вы можете позволить Reform автоматически копировать их.

...

Имейте в виду, что мы не поощряем копирование проверок. Вы должны скорее перенести проверочный код в формы и больше не работать с вашей моделью.

Какое обоснование дает проект Gem для проведения реформ или его авторы за отсутствие проверки в моделях?

Answer 1

Я бы разделил проверки на две разные категории:

• Целостность данных
• Бизнес Логика

Целостность данных означает, что модель нельзя использовать без соответствия определенным критериям. Вы должны убедиться, что модель никогда не будет считаться действительной в этом состоянии. Однако в большинстве случаев это касается таких вещей, как уникальность, которые связаны с постоянством. Таким образом, эти ограничения лучше применять на уровне базы данных, а не в модели.

Бизнес-логика, с другой стороны, напрямую связана с функциональными потребностями приложения.

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

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

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

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