Один из комментаторов указывает: «Вы захотите получить набор ошибок валидации». Это важно.
По моему опыту, методы валидации внутри их модельных объектов не работают, потому что логика валидации часто меняется и потому, что что-то, что недопустимо при одном наборе обстоятельств, допустимо при другом наборе обстоятельств. Например, если метод проверки считает что-либо недопустимым после 9 часов вечера, администратор школы может изменить правила так, чтобы курсы в течение летнего квартала продолжались до 23 часов. Вы не хотите застрять с вашим методом проверки в вашем классе, когда такое происходит, как это неизбежно происходит.
Кроме того, зачастую невозможно проверить объект, не зная о состоянии других объектов в системе. Например, если у вас есть объект ссуды, значения ссуды, превышающие 100 000 долл. США, могут быть недопустимыми, ожидайте, когда объект Customer имеет тип Institution. Вам необходимо знать об объектах «Заем» и «Клиент», чтобы правильно проверить Заем.
Лучшие практики, которые я видел для комплексной проверки:
Допустимые простые вещи до принятия объекта. Это включает проверку на наличие недопустимых символов или нецифровых числовых полей.
Создание структуры проверки, которая проверяет группу зависимых объектов одновременно. Не останавливайте процедуру проверки при первой обнаруженной ошибке. Вместо этого создайте класс с именем ValidationError, и ваша платформа создаст коллекцию этих объектов. Этот подход позволяет вам учитывать внутриобъектные и межобъектные зависимости. Кроме того, вы можете сразу представить все ошибки пользователю, вместо того, чтобы заставлять его исправлять ошибки по одному.
Не задавайте жесткие значения кода, такие как минимальный-числовой-студенческий или последний-минимальный класс. Вместо этого поместите эти значения в таблицу реляционной базы данных или файл конфигурации. Заставьте платформу проверки искать правильные значения (и затем кэшировать их). Когда значения меняются (как это часто бывает), вам нужно всего лишь обновить файл или базу данных; нет необходимости перестраивать и заново развертывать все приложение. Когда я делал эту работу, я программировал на Smalltalk. Если вы используете динамический язык, такой как Smalltalk или Ruby, легко поместить исходный код в вашу базу данных как «блок проверки» и выполнить его во время выполнения.
Среда проверки может использовать исключения, но я рекомендую против этого. Исключения должны быть зарезервированы для более радикальных ошибок, которые сложнее исправить. Кроме того, исключения могут привести к значительному снижению производительности, что важно, если проверка выполняется на сервере, а не на клиенте. Хуже всего то, что несколько платформ имеют шаткую обработку исключений.