数据库异常处理的最佳实践[英] Database exception handling best practices

本文是小编为大家收集整理的关于数据库异常处理的最佳实践的处理/解决方法,可以参考本文帮助大家快速定位并解决问题,中文翻译不准确的可切换到English标签页查看源文。

问题描述

您如何处理应用程序中的数据库异常?
您是在将数据传递给数据库之前尝试验证数据还是仅仅依赖数据库架构验证逻辑?
您是否尝试从某种数据库错误(例如超时)中恢复?

这里有一些方法:

  1. 在将数据传递给 DB 之前验证数据
  2. 将验证留给 DB 并正确处理 DB 异常
  3. 双向验证
  4. 验证业务逻辑中一些明显的约束,并将复杂的验证留给 DB

您使用什么方法?为什么?

更新:

我很高兴看到越来越多的讨论.
让我们尝试总结社区的答案.

建议:

你还有什么要说的吗?这将转换为验证特定问题.我们缺少核心,即"与数据库相关的错误最佳实践",哪些要处理,哪些要冒泡?

推荐答案

@aku:DRY 很好,但并不总是可行.验证就是其中之一,因为您将拥有三个完全不同且不相关的地方,验证不仅可能而且绝对需要:在 UI 内、业务逻辑内和数据库内.

想想一个网络应用程序.您希望减少对服务器的访问,因此您包括客户端数据输入的 javascript 验证.但是您不能相信用户输入的内容,因此您必须在接触数据库之前在业务逻辑中执行验证.并且数据库必须有自己的验证,以防止数据损坏.

没有一种简洁的方法可以将这三种不同类型的验证统一在一个组件中.

正在尝试统一跨领域职责,例如 P&P 小组的 策略注入应用程序块 结合他们的 验证应用程序块,但这些仍然是基于代码的.如果您有代码中没有的验证,您仍然需要单独维护并行逻辑...

本文地址:https://www.itbaoku.cn/post/597654.html

问题描述

How do you handle database exceptions in your application?
Are you trying to validate data prior passing it to DB or just relying on DB schema validation logic?
Do you try to recover from some kind of DB errors (e.g. timeouts)?

Here are some approaches:

  1. Validate data prior passing it to DB
  2. Left validation to DB and handle DB exceptions properly
  3. Validate on both sides
  4. Validate some obvious constraints in business logic and left complex validation to DB

What approach do you use? Why?

Updates:

I'm glad to see growing discussion.
Let’s try to sum up community answers.

Suggestions:

  • Validate on both sides
  • Check business logic constraints on client side, let DB do integrity checks from hamishmcn
  • Check early to avoid bothering DB from ajmastrean
  • Check early to improve user experience from Will
  • Keep DB interacting code in place to simplify development from hamishmcn
  • Object-relational mapping (NHibernate, Linq, etc.) can help you to deal with constrains from ajmastrean
  • Client side validation is necessary for security reasons from Seb Nilsson

Do you have anything else to say? This is converted to Validation specific question. We are missing the core, i.e. "Database related Error best practices" which ones to handle and Which ones to Bubble up?

推荐答案

@aku: DRY is nice, but its not always possible. Validation is one of those places, as you will have three completely different and unrelated places where validation is not only possible but absolutely needed: Within the UI, within the business logic, and within the database.

Think of a web application. You want to reduce trips to the server, so you include javascript validation of client data entry. But you can't trust what the user enters, so you must perform validation within your business logic before touching the database. And the database must have its own validation in order to prevent data corruption.

There's no clean way to unify these three different types of validation within a single component.

There are some attempts being made to unify cross-cutting responsibilities like validation within policy injectors like the P&P group's Policy Injection Application Block combined with their Validation Application Block, but these are still code based. If you have validation that's not in code, you still have to maintain parallel logic separately...