Передовая практика обработки исключений баз данных

Ответ 1

@aku: DRY приятно, но это не всегда возможно. Валидация является одним из этих мест, так как у вас будет три совершенно разных и несвязанных места, где валидация не только возможна, но и абсолютно необходима: внутри пользовательского интерфейса, в бизнес-логике и в базе данных.

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

Нет никакого чистого способа унифицировать эти три разных типа проверки в рамках одного компонента.

Предпринимаются попытки унифицировать межсекторальные обязанности, такие как валидация внутри политических инжекторов, таких как группа P & P group блок приложения для внедрения политики с их Блок приложений проверки, но они все еще основаны на коде. Если у вас есть проверка, что не в коде, вам все равно придется поддерживать параллельную логику отдельно...

Ответ 2

Существует одна причина убийства для проверки как на стороне клиента, так и на стороне базы данных, а это безопасность. Особенно, когда вы начинаете использовать AJAX-материал, взломанные URL-адреса и другие вещи, которые делают ваш сайт (в данном случае) более дружественным для пользователей и хакеров.

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

Ответ 3

Вы хотите уменьшить ненужные поездки в БД, поэтому выполнение проверки в приложении является хорошей практикой. Кроме того, он позволяет обрабатывать ошибки данных, из которых наиболее легко восстановить: около пользовательского интерфейса (будь то в контроллере или в пределах слоя пользовательского интерфейса для более простых приложений), где вводятся данные.

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

Где вы имеете дело с ошибками, возвращаемыми вызовами базы данных, является интересным. Вы можете иметь дело с ними на уровне данных, уровне бизнес-логики или уровне пользовательского интерфейса. Лучшей практикой в ​​этом случае является то, чтобы эти ошибки доходили до последнего ответственного момента перед их обработкой.

Например, если у вас есть веб-приложение ASP.NET MVC, у вас есть три уровня (снизу вверх): база данных, контроллер и пользовательский интерфейс (модель, контроллер и представление). Любые ошибки, сброшенные вашим уровнем данных, должны быть разрешены для ввода пузырьков в ваш контроллер. На этом уровне ваше приложение "знает", что пытается сделать пользователь, и может правильно информировать пользователя об ошибке, предлагая различные способы его обработки. Попытка восстановить эти ошибки в пределах уровня данных затрудняет понимание того, что происходит внутри контроллера. И, конечно, размещение бизнес-логики в пользовательском интерфейсе не считается лучшей практикой.

TL; DR: проверять всюду, обрабатывать ошибки проверки в последний ответственный момент.

Ответ 4

Я пытаюсь проверить с обеих сторон. 1 правило, которое я всегда соблюдаю, никогда не является доверительным вкладом от пользователя. Следуя этому выводу, обычно у меня будет какая-то проверка на лицевой стороне на странице формы/веб-страницы, которая даже не позволит подчиняться с неправильно сформированными данными. Это тупой инструмент - это означает, что вы можете проверить/проанализировать значение, чтобы убедиться, что поле даты содержит дату. Оттуда я обычно позволяю моей бизнес-логике проверять, имеет ли смысл ввод данных в контексте того, как он был отправлен. Например, представленная дата попадает в ожидаемый диапазон? Представлена ​​ли валютная стоимость в ожидаемый диапазон? Наконец, на стороне сервера ограничения и индексы внешнего ключа могут перехватывать любые ошибки, которые проскальзывают, что вызовет исключение БД в качестве последнего средства, которое может быть обработано кодом приложения. Я использую этот метод, потому что он отфильтровывает как можно больше ошибок до вызова БД.

Ответ 5

Инструмент объектно-реляционного сопоставления (ORM), например NHibernate (или, еще лучше, ActiveRecord), может помочь вам избежать большого количества валидации, разрешив построить модель данных прямо в ваш код как подходящий класс С#. Вы также можете избежать поездок в базу данных, благодаря отличным моделям кэширования и валидации, встроенным в инфраструктуру.

Ответ 6

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

Ответ 7

Виды приложений, которые я пишу (с тех пор я переместил задания), были внутренними программами для жирного клиента.
Я бы постарался сохранить бизнес-логику в клиенте и сделать более механическую проверку на db (т.е. Валидацию, связанную только с способностью процедуры, в отличие от проверки более высокого уровня).
Короче говоря, подтвердите, где вы можете, и попытайтесь сохранить связанные типы проверки вместе.