asp.net - 如何以及在何处处理 3 层 Web 应用程序中的异常？特别是Sql数据库异常

Question

我正在构建标准的 3 层 ASP.NET Web 应用程序，但我很难知道在哪里执行某些操作 - 特别是处理异常。

我尝试在网络上查找一些示例，但找不到任何可以显示所有内容如何链接在一起的整个项目的示例。

在我的数据层中，我正在连接到 SQL Server 并执行一些操作。我知道我需要捕获可能因此引发的异常，但我不确定在哪里执行此操作。

根据我读到的内容，我应该在 UI 层执行此操作，但在这种情况下，我不确定如何确保关闭与数据库的连接。有人能够澄清如何做到这一点吗？另外，如果有人知道我在哪里可以找到遵循最佳实践的示例 3 层 Web 应用程序，那就太好了。

谢谢

Answer 1

没有简单的答案或模式可以确保成功。就像您的验证策略一样，您的确切异常处理策略特定于您的具体情况，并且通常是时间和全面性之间的权衡。不过，我们可以提供一些好的建议:

• 永远不要隐藏堆栈跟踪；永远不要使用“重新抛出”，除非出于安全目的您想隐藏发生的事情。
• 不要觉得到处都需要错误处理。默认情况下，在较低层中，让实际错误渗透到顶层也不错。 UI/ Controller 是您必须真正决定如何对出现问题使用react的地方。
• 在任何时候，如果出现问题，您自己到底希望发生什么。通常，您无法想到比让它上升到顶层甚至客户端计算机更好的方法。 (尽管在详细报告的生产过程中。)如果是这种情况，那就随它去吧。
• 确保处置非托管资源(任何实现 IDisposable 的资源)。您的数据访问就是一个很好的例子。 (A) 在 Finally block 中为您的(特别是)连接、命令、数据读取器等调用 .Dispose()，或者 (<强>B)使用Using Syntax/Pattern这确保了正确的处置发生。
• 查找可能出现错误的位置以及可以查找某些错误的位置，使用react(通过重试、等待第二次重试、以不同的方式尝试该操作等)，然后希望成功。异常处理的大部分目的是为了成功，而不仅仅是很好地报告失败。
• 在数据层中，您必须考虑如果在多步骤过程中出现问题该怎么办。您可以让实际错误渗透出去，但该层必须处理错误后的整理工作。有时您会想要使用事务。
• 在异步情况下(要么(A.)因为多个线程，要么(B.)因为业务逻辑是在“任务机器”等上单独处理并稍后执行)，您特别需要制定一个计划记录错误。
• 我宁愿在应用的 25% 中看到“错误处理代码”，而不是在 100% 中看到“错误处理代码”。 100% 意味着您可能希望它看起来像有错误处理功能。 25% 意味着您花时间处理真正需要处理的异常。