2011-01-27 1 views
13

Я читал противоречивые соображения о том, где должно выполняться валидация данных, и это меня просто сбивает с толку. Некоторые говорят, что это должно быть только в базе данных. Другие говорят, что правила проверки должны быть отражены в других слоях, таких как bll или ui.Где должна производиться проверка данных?

Где должна храниться информация? Должны ли разделяться правила на нескольких уровнях? Каковы некоторые из лучших практик (в отличие от теории, голова в материале типа облаков) относительно того, когда и где проверять данные в приложении, работающем поверх базы данных.

+2

Это, безусловно, должно быть на бэкэнд - и если это возможно и поможет вашему приложению, то также выполните проверку в интерфейсе. Но никогда не полагайтесь только на проверку на лицевой стороне - никогда не доверяйте никаким данным, прежде чем вставлять их в свою базу данных. ** ** всегда проверяйте на уровне базы данных (ссылочная целостность, ограничения CHECK и т. Д.) - никаких исключений. –

ответ

8

Мои 2 цента:

Проверка данных должна происходить в двух местах:

  1. Точка, в которой данные действует, например, проверки входных параметров для запроса SQL.

  2. Общая проверка в момент отправки данных, например в веб-приложении, на клиенте должна выполняться некоторая проверка. Преимущество состоит в том, что вы можете быстро уведомлять пользователей о проблемах ввода, т. Е. Неправильно сформированный номер телефона, слишком длинную строку и т. Д. Однако на это нельзя полагаться на авторитарную проверку проверки, так как, в случае веб-приложения, злоумышленник может обойти проверку на стороне клиента.

По моему мнению, база данных не следует выполнять общие проверки, данные должны быть проверены/спасся/продезинфицировать, прежде чем он попадает в базу данных. Тем не менее, ваша схема базы данных может дать вам уровень абстрактной проверки по типам данных столбцов, ограничениям и т. Д. Таким образом, любые данные, которые могут вызывать проблемы с ними, должны быть очищены до того, как они будут переданы в базу данных.

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

+0

Тогда вы никогда не выполнили запрос базы данных, в котором была бы ошибка (ошибки, отличные от приложения, как проблемы с подключением). По сути, ваше приложение выполняет всю проверку, которая должна произойти. Правильно ли это звучит? – Jeff

+1

Вы никогда не можете быть абсолютно уверены, что ваш запрос БД не вызовет ошибку из-за плохих данных, поэтому ваше приложение должно это обработать. Однако вы можете многое сделать, чтобы этого не происходило. Обычно базы данных могут выполнять базовую валидацию (ограничения, типы данных и т. Д.), Но сложнее справляться с чем-либо, кроме того, имея возможность грамотно обрабатывать ошибки проверки. Кроме того, зачем загружать базу данных с запросами, которые содержат не прошедшие проверку данные, ваше приложение может справиться с этим, и гораздо проще масштабировать приложение, чем масштабировать базу данных. – MrEyes

3

это должно быть сделано:

  • в точке он впервые вошел
  • где-нибудь по пути он изменил/манипулируют
  • где-нибудь по пути, это может привести к ошибке или неверные данные

поэтому в приложении с ведомыми базами данных, например, у вас будет проверка на JavaScript на стороне клиента, возможно, на стороне проверки на стороне сервера в бизнес-логике, а затем в дальнейшем constr в базе данных, начиная от типа данных и заканчивая ограничениями проверки.

+0

Вы дублируете все правила на каждом уровне? Если нет, как вы определяете, какие правила входят в какой слой? – Jeff

+0

, если вы следуете приведенным выше рекомендациям, и это означает, что вам нужно добавить проверку на каждый уровень, а затем добавить проверку на каждый уровень. Это по достоинству, а не по некоторому правилу, которое может не соответствовать вашему приложению. – iain

+0

+1 для лучшего описания логики логики как сквозной задачи. –