Проверка данных: быстрый отказ, ранний отказ или полная проверка
Что касается проверки данных, я слышал, что есть варианты "быстро провалиться, рано провалиться" или "завершить проверку". Первый подход терпит неудачу при самой первой ошибке проверки, тогда как второй формирует список сбоев и представляет его.
Мне интересно об этом в контексте проверки данных как на стороне сервера, так и на стороне клиента. Какой метод подходит, в каком контексте и почему?
Мое личное предпочтение в проверке данных на стороне клиента - второй метод, который информирует пользователя обо всех сбойных ограничениях. Я не достаточно информирован, чтобы иметь мнение о серверной стороне, хотя я думаю, что это зависит от бизнес-логики.
2 ответа
Отчасти это сбивает с толку то, что люди не обсуждают ортогональность как часть критериев. "Fail-early" полезен для того, чтобы ошибка обнаруживалась там, где она возникает, а не вниз по течению. Но для ортогональных отказов нет ни нисходящего, ни множественных нисходящих потоков.
Например, большинство пользовательских форм заполнены множеством независимых вопросов, таких как имя пользователя, пароль, электронная почта, например. Поскольку они независимы, подождите, пока все 3 не появятся, и опишите все ошибки сразу. Заставлять пользователя проходить три цикла отправки-проверки-жалобы нелепо.
В случае простых ошибок, таких как неверные данные или пропущенные данные, вам решать, насколько удобно создать систему для пользователя. Например, это может быть очень неприятно, если кто-то импортирует полную таблицу данных в систему, и первая строка завершилась неудачно, а вы сказали "первая строка не удалась". Пользователь исправляет первую строку, импортирует и получает сообщение "Ошибка второй строки". Представьте, что есть 65536 строк. Вы уже знаете, что не будете ничего делать с данными, но хотите ли вы сделать жизнь пользователя проще? Опять же, это тривиальные ошибки, которые я обсуждаю, и, конечно, вы будете разрабатывать систему, которая проверяет все данные перед обработкой.
Для более серьезных ошибок, которые вы или не ожидаете, или которые являются чем-то большим, чем просто проблемы проверки, вернитесь к провалу быстро и сильно.