数据库异常处理最佳做法 [英] Database exception handling best practices

问题描述

如何处理应用程序中的数据库异常？

您是否尝试在将数据传递给数据库之前验证数据，或者仅依靠数据库模式验证逻辑？

您尝试从某种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)?

这里有一些方法：

1. 在将数据传递给DB之前验证数据


2. 向DB确认并正确处理数据库异常


3. 验证双方


4. 验证业务逻辑中的一些明显的约束，并将复杂的验证留给DB

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?

更新：

我很高兴看到日益增长的讨论。

我们试着总结一下社区的答案。

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

建议：

• 验证双方


• 检查
  客户端的业务逻辑约束，让DB做完整性检查 from hamishmcn


• 及早检查以避免烦扰DB 从ajmastrean


• 提前检查以改善用户体验


• 保持数据库交互代码到位
  简化开发 from hamishmcn


• 对象关系映射（NHibernate，Linq等）可以帮助您处理约束


• 出于安全原因，客户端验证是必要的从Seb Nilsson

• 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很好，但并不总是可能的。验证是其中之一，因为您将有三个完全不同且无关的地方，其中不仅可以验证，而且绝对需要：在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.

想想一个Web应用程序。您希望减少到服务器的行程，因此您可以包括客户端数据输入的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组的策略注入应用程序块与他们的验证应用程序块，但这些仍然是基于代码的。如果您的验证不在代码中，则您仍然需要分别维护并行逻辑。

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屋！