数据库异常处理最佳实践 [英] Database exception handling best practices
问题描述
您如何处理应用程序中的数据库异常?
您是尝试在将数据传递给 DB 之前对其进行验证，还是仅仅依靠 DB 模式验证逻辑?
您是否尝试从某种数据库错误(例如超时)中恢复?
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)?
这里有一些方法:
- 在将数据传递给 DB 之前验证数据
- 将验证留给 DB 并正确处理 DB 异常
- 双方验证
- 验证业务逻辑中的一些明显约束，并将复杂的验证留给 DB
您使用什么方法?为什么?
What approach do you use? Why?
更新:
我很高兴看到越来越多的讨论.
让我们尝试总结社区的答案.
I'm glad to see growing discussion.
Let’s try to sum up community answers.
建议:
- 双方验证
- 检查业务逻辑约束客户端，让 DB 做完整性检查 来自 hamishmcn
- 尽早检查以避免打扰数据库来自ajmastrean
- 尽早检查以改善用户体验 来自 Will
- 保持数据库交互代码到位简化开发 来自 hamishmcn
- 对象关系映射(NHibernate、Linq 等)可以帮助您处理约束来自ajmastrean
- 出于安全原因，必须进行客户端验证来自 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 很好，但并不总是可行.验证就是其中之一，因为您将在三个完全不同且不相关的地方进行验证，验证不仅可能而且绝对必要:在 UI 内、业务逻辑内和数据库内.
@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.
想想一个网络应用程序.您想减少到服务器的行程，因此您包括客户端数据输入的 javascript 验证.但是您不能信任用户输入的内容，因此您必须在接触数据库之前在您的业务逻辑中执行验证.并且数据库必须有自己的验证以防止数据损坏.
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.
正在尝试统一跨领域职责，例如 P&P 组的 Policy Injection Application Block 结合他们的 验证应用程序块，但这些仍然是基于代码的.如果您的验证不在代码中，您仍然需要单独维护并行逻辑...
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...
这篇关于数据库异常处理最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
