2

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

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

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

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

    或者

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

4

2 回答 2

1

1是更好的全方位解决方案。数据库调用不是唯一昂贵的操作，异常也很昂贵。您真的应该只让您的数据库在由于您的代码而不是用户操作而出现问题时抛出异常。

例如，您稍后可能想要安装 Elmah 并记录和/或邮寄给您的异常。Elmah 会记录/发送这样的异常，除非你明确告诉它不要这样做。

另外，就像您说的那样，异常并不总是具有与用户交流的最商业信息（尤其是 SQL 异常，它是特定于 SQL 的）。你有这些独特的和其他的限制是有原因的。由于这些原因，请在尝试存储信息之前验证信息。

拿 twitter、gmail 等。当你去获取用户名时，应用程序首先检查它是否被占用。这些是应用程序级别的唯一性约束，最终可能会或可能不会被实现为 SQL 约束。由于面向用户的是您的应用程序，因此您不应尝试通过将 SQL 翻译成英语来与他们交流。

于 2012-07-19T07:49:21.817 回答
0

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

这并不排除在尝试提交之前使用一些 UI 层验证来增强您的应用程序以帮助用户。

因此，如果放弃它，我们就剩下选项 2，并且在应用程序的某个地方需要进行一些翻译。你把翻译和逻辑放在哪里，无论是在存储过程还是业务逻辑层，都取决于你。

于 2012-07-19T12:46:28.723 回答