database - это - собственные исключения java




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

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

Вот несколько подходов:

  1. Проверять данные перед передачей их в БД
  2. Левая проверка правильности DB и обработка исключений DB
  3. Подтверждать с обеих сторон
  4. Подтвердите некоторые очевидные ограничения в бизнес-логике и оставите комплексную проверку в DB

Какой подход вы используете? Зачем?

Обновления:

Я рад видеть растущее обсуждение.
Попробуем подытожить ответы сообщества.

Предложения:

  • Подтверждать с обеих сторон
  • Проверьте ограничения бизнес-логики на стороне клиента, дайте БД выполнить проверки целостности с hamishmcn
  • Проверьте рано, чтобы не беспокоиться о DB от ajmastrean
  • Проверьте рано, чтобы улучшить пользовательский опыт от Will
  • Сохраните код взаимодействия с БД, чтобы упростить разработку от hamishmcn
  • Объектно-реляционное сопоставление (NHibernate, Linq и т. Д.) Может помочь вам справиться с ограничениями от ajmastrean
  • Важная проверка на стороне клиента необходима по соображениям безопасности Seb Nilsson

У вас есть что сказать? Это преобразуется в конкретный вопрос проверки. Нам не хватает ядра, т. Е. «Лучшая практика ошибок, связанных с базой данных», какие из них обрабатывать, а какие - Bubble?


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

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

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

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


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


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

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

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

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

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


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


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

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





architecture