在C＃中捕获破坏的数据库约束 - 最佳实践

Question

假设我有一个SQL表，其中一列上有唯一的键（或其他）约束。

然后，我有一个允许用户编辑此列的应用程序（让我们去ASP.NET MVC）。

当用户尝试保存，并且约束将被破坏时，我需要向用户显示用户友好的错误消息。因此，以下哪项是更好的做法？

1. 让应用程序查询数据库以确保约束不被破坏，然后插入/更新行（导致对db进行两次查询）

   OR

2. 立即尝试执行插入/更新，并在约束被破坏时捕获SqlException。我喜欢这个，因为只有一次访问db，但是你应该如何提取哪个索引/约束被破坏并附加相应的消息？ （除了检查Exception.Message？）

Answer 1

1是更好的全方位解决方案。 Db调用不是唯一昂贵的操作，异常也是昂贵的。实际上，只有当你的代码出错而不是用户操作时，才会让你的db抛出异常。

例如，您稍后可能希望安装Elmah并获取记录和/或邮寄给您的异常。 Elmah会记录/邮寄此类例外情况，除非您明确告知不要这样做。

正如你所说，异常并不总是有最商业化的信息与用户沟通（特别是SQL异常，这是特定于SQL的）。出于某种原因，您有这些唯一和其他约束。出于这些原因，请在尝试存储之前验证信息。

使用twitter，gmail等。当你去获取用户名时，应用程序首先检查它是否被采用。这些是应用程序级别的唯一性约束，最终可能会或可能不会实现为SQL约束。由于您的应用程序面向用户，因此您不应尝试通过从SQL转换为英语与他们进行通信。

Answer 2

选项1的问题在于它要求应用程序对约束是什么有独立的不同知识，哪些与DRY原则冲突，并且可能在以后数据库约束发生更改时导致问题，并且应用程序不是更新 - 数据逻辑与应用程序之间的紧密耦合。此外，当您尝试更新时，无法保证在随后的pont中执行的约束检查仍然有效。

这并不排除使用某些UI层验证来扩充您的应用程序，以在尝试提交之前为用户提供帮助。

因此，如果将其丢弃，我们将留下选项2，并且在应用程序的某处需要进行一些翻译。无论是在存储过程还是业务逻辑层中，您放置该转换的逻辑都取决于您。