Где хранить логику валидации

Question

ОК, я видел другие посты по этому поводу, но никто не ответил конкретно на мой вопрос.

Где в приложении должна быть логика проверки?

У меня есть небольшое приложение, которое позволяет добавлять новые продукты в базу данных приложений. Существуют разные продукты с разными полями, т. Е. Название продукта, номер заказа, описание и т. Д. Можно вставить новые продукты и обновить существующие. Поэтому, когда новый продукт вставляется, тогда все поля должны быть проверены, но когда существующий продукт обновляется, необходимо проверять только обновляемые поля, т. Е. Может быть, обновляется только описание, поэтому проверяется только это поле. *

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

У меня такое ощущение, что для этого должен быть лучший шаблон - какой-нибудь совет?

Answer 1

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

Но я всегда проверял бы весь объект.Разбираться в том, что было изменено, и проверять только то, что кажется излишним.Если, конечно, вы точно не знаете (измеряя), что это будет проблемой производительности.

Answer 2

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

1. На стороне клиента обязательные поля могут быть проверены после добавления пользовательского интерфейса.контроль;строки, которые должны соответствовать регулярным выражениям, таким как «гггг-мм-дд» для дат, должны быть проверены.В веб-интерфейсах это обычно делается с использованием JavaScript.
2. На стороне сервера объекты должны проверяться на достоверность, так как входные параметры связаны.
3. Действующие объекты по-прежнему необходимо проверять на «деловую действительность» при обработке (например, «требуется действительный номер кредитной карты при оплате кредитной картой»).

Вы должны выполнить как клиентскую, так и серверную проверку.Привязка и проверка выполняется вашим уровнем обслуживания, когда ввод связан с объектами.Они также проверяют соответствие бизнес-правилам при обработке для выполнения варианта использования.

Answer 3

Где в приложении должна быть логика проверки?

Зависит от вашей архитектуры. Валидация может быть выполнена в несколько этапов для достижения оперативности. Как правило, хотя модель / контроллер кажется хорошим местом в данной архитектуре MVC. Этот вопрос возник когда-то на старом форуме Джоэла в контексте архитектуры MVC . Представляется вероятным, что модель должна отвечать за принятие / отклонение ввода.

Поэтому, когда появляется новый продукт вставлены тогда все поля должны быть подтверждено

Да.

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

Вы не можете предсказать, какая именно часть будет обновлена. Итак, вам нужно написать валидаторы для всех полей (столбцов вашей базы данных).

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