У меня есть метод «ABC», который делает некоторые вещи. Метод ABC вызывается из другого метода, метод XYZ. Где должна проводиться проверка данных входных значений?Где должна проводиться проверка данных?
Должен ли я проверять в XYZ перед тем, как позвонить ABC? Если это плохой метод данных, ABC даже не будет вызван.
Или, следует ли проверять в ABC?
Или, проверьте в обоих местах?
Это зависит.
Если ABC только когда-либо вызывается XYZ, то вы можете подтвердить его с помощью XYZ.
Если ABC имеет видимость вне XYZ (например, это общедоступный метод или внутренний), вы должны подтвердить его в ABC.
Если это критическая функция (ABC = AtomicBombControl), то проверяйте всюду, где можете.
If it's bad data method ABC won't even be called.
Я думаю, что у вас есть ответ на ваш вопрос :)
Я смотрю ряд соображений:
Насколько важно данные правильно.
Где это может быть неправильно.
Где находится наиболее эффективное и эффективное место для его проверки.
Где лучше всего это исправить.
Скорее всего, ваши плохие данные будут поступать из пользовательского интерфейса, и вы также можете запросить его исправление.
Ссылочные и уникальные ограничения наиболее эффективно обрабатываются в базе данных. Код, который изменяет базу данных, должен поймать их и передать полезное исключение обратно в пользовательский интерфейс.
Проверка на несколько раз стоит накладных расходов, если правильность действительно важна, а ошибки в коде могут приводить к плохим данным на заднем конце. Я выполняю несколько проверок на такие вещи, как финансовые данные или что-то, что может привести к сбою всей системы.
Быстрый отказ - это хорошо. Вы должны сообщить о плохих данных, как только сможете это определить. Итак, если вы знаете, что данные плохие в XYZ, то выкиньте исключение в XYZ. Метод ABC не имеет смысла, если данные уже плохие.