Обеспечить достоверность данных или защиту от неверных данных? И то и другое? - PullRequest
2 голосов
/ 16 июля 2009

Я хотел бы знать, в практическом смысле, в крупномасштабном (Java - мой случай) проекте лучше всего просто написать защитную логику для защиты от недопустимых данных в БД или просто потратить время на прохождение и убедитесь, что вы не принимаете какие-либо неверные данные? Помните, проблема здесь в том, что во многих случаях нулевое значение в порядке, и во многих случаях нулевое значение отсутствует, поэтому случай, когда нет недопустимых данных, не является тривиальным.

Причина, по которой я спрашиваю, заключается в том, что я работаю над большим проектом и обнаруживаю, что гоняюсь за некоторыми неприятными исключениями нулевого указателя, только чтобы понять, что причина его выбрасывания заключается в том, что какое-то неясное свойство большого объекта не установлено. Итак, я пойду поговорить с системным инженером только для того, чтобы понять, что в проекте должно быть задано пользователем и т. Д.

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

Спасибо!

** Мне только что пришло в голову, что многие могут посчитать этот вопрос самоуверенным? Если это так, то каждый может сделать это вики-сообществом. Я не уверен, хотя. Может быть, существует некое соглашение или «хорошая практика», о которых многие не знают, и в последующем это не был бы самоуверенный вопрос, просто вопрос информирования меня, нового разработчика, об этой практике.

Ответы [ 3 ]

4 голосов
/ 16 июля 2009

Я склонен писать свои объекты для проверки при строительстве (в основном мои объекты неизменны). Сеттеры также будут проверять.

Проверки включают проверки на нулевые значения (наиболее распространенные - я стараюсь очень трудно предотвратить нулевые значения, и код комментария, когда допустимо нулевое значение), некоторые проверки работоспособности значений Это приведет к IllegalArgumentExceptions при сбое (обычно)

Когда я выполняю эти проверки? Не для каждого объекта / вспомогательного объекта и т. Д. Обычно в каком-то переходе между соответствующими слоями или наборами компонентов в моем приложении. Хорошее практическое правило заключается в том, что любой компонент, который может быть повторно использован новым клиентом, будет выполнять проверку. Таким образом (в вашем примере) уровень базы данных будет обеспечивать проверку, обычно независимо от других уровней (это не является необоснованным, если вы считаете, что разные уровни приложения представляют данные в разных формах)

Уровень проверки зависит от источника этих данных. например проверки выполняются наиболее строго при вводе пользователем (например, записи в текстовых полях и т. д.). Я менее строгий для проверки ввода, который поступит, скажем, из конфигурации Spring XML.

Валидация чрезвычайно важна. Вы проверяете свои данные немедленно , а не тогда, когда это вызовет проблему. Это делает жизнь намного проще (представьте, если вы принимаете неверный ввод, сериализуете объект, десериализуете его через год и обнаруживаете, что не можете его использовать!)

1 голос
/ 16 июля 2009

Используйте ограничения базы данных (например, NOT NULL), чтобы каким-либо образом запретить неверные данные в базе данных, и подтверждение ввода в коде приложения Java, чтобы запретить пользователю вводить недействительные данные. данные.

Недостаточно только ограничений базы данных, поскольку пользователь должен видеть значимые сообщения об ошибках проверки. И одной только проверки входных данных недостаточно, потому что данные в базе данных должны быть в допустимом состоянии, даже если во входном коде проверки есть ошибки. Кроме того, данные в базе данных не обязательно должны поступать из вашего приложения.

0 голосов
/ 16 июля 2009

Если пользователь должен ввести данные, которые впоследствии будут проверены на достоверность, вы не должны принимать какие-либо данные, пока пользователь не заполнит обязательные поля. Не имеет смысла принимать неполные данные и записывать неполные данные в базу данных.

Однако вам также необходимо проверить данные при извлечении их из БД, прежде чем пытаться либо работать с ними, либо передать их обратно пользователю. Возможно, данные изменились из какого-то внешнего источника, возможно, данные просто повреждены, но вам нужно проверить их.

Таким образом, настоящий ответ - «оба раза». Вы должны проверить это на обоих концах.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...