Для меня самое естественное место в модели, потому что оно содержит данные. В Принципе экспертов GRASP говорится, что вы должны назначать обязанности объекту, который имеет информацию для их выполнения.
Мы можем утверждать, что контроллер может иметь всю информацию (данные), необходимую для проверки, но для меня контроллеры должны быть легкими. Более того, я считаю, что «вся информация» означает не только наличие данных, которые вы должны подтвердить, но также знание их формата, и это проблема модели. Контроллер может знать, как должны быть данные, которые должна удовлетворять определенная модель, но эта модель также может использоваться вне этой области управления, поэтому она не должна полагаться на проверку контроллера, чтобы работать хорошо, поскольку модель (почти) имеет последний шанс обнаруживать недействительные данные (вы можете и должны также делать это в базе данных, но данные должны быть проверены и дезинфицированы до того, как они войдут в него, хотя обычно есть прямая совпадение между схемой базы данных и валидацией, которую вы должны делать в модели) ,
Каждый раз, когда вы выполняете операции CRUD с моделью, вам, вероятно, придется проверять данные, и вы убедитесь, что ваши данные почти всегда правильны. Более того, контроллер мог также изменить данные, которые затем попадают в эту модель, поэтому, даже если контроллер проверил это ранее, он может привести к недействительным данным.
Однако подумайте об этом. Контроллер может изменить данные и на самом деле много времени они делают. Необычно всегда иметь прямую карту между полями в форме и моделью, и иногда у вас будут входные данные, которые не имеют ничего или мало общего с какой-либо моделью, поэтому вы должны проверить их вне модели. Например, подумайте о поле «Повторить пароль». Это не имеет никакого отношения к модели! Только поле «Пароль» должно достигнуть этого.
Другие люди скажут, что предпочитают anemic models, и в некоторых сценариях они могут поместиться лучше, чем богатые, но у них также есть некоторые недостатки и богатые, которые лучше всего подходят в целом.
Вы также должны рассмотреть вопрос о валидации на стороне клиента (например, JS), чтобы вы могли дать ему быструю обратную связь о том, что он делает, вместо того, чтобы отправлять данные на сервер для проверки, а затем ждать ответа или даже снова загрузите всю страницу!
Один хороший способ сделать это - использовать регулярное выражение, потому что у вас будут похожие выражения между разными языками, которые вы используете, хотя чаще всего этого будет недостаточно. Или лучше, вы можете использовать JS везде с Node.js и полностью забыть об этой проблеме.
Возможно, это не тот ответ, который вы искали, но есть не один правильный способ сделать проверку, поскольку он отличается для каждого приложения.В большинстве случаев проверка должна выполняться в разных местах, выполняя ту же проверку в некоторых разных слоях вашего приложения и различную проверку между некоторыми другими.
Есть еще вопросы по этой теме на StackOverflow, так что вы можете проверить их, чтобы иметь разные мнения от других людей:
Обратите внимание, что валидация и дезинфекция другие вещи. Вы проверяете как можно быстрее; вы санируете как можно безопаснее. Вы можете проверить имя пользователя с регулярным выражением на странице регистрации, но вы дезинфицируете его после того, как он находится на вашем сервере, или кто-то может использовать консоль для отправки несаминированной версии, минуя хороший кусок вашей безопасности. –