如何以及在何处处理3层Web应用程序中的异常？特别是Sql Database Exceptions

Question

我正在构建标准的3层ASP.NET Web应用程序,但我在努力去做某些事情 - 特别是处理异常.

我试图在网上浏览一些例子,但找不到任何一个整个项目,显示一切如何链接在一起.

在我的数据层中,我正在连接到SQL Server并做一些事情.我知道我需要捕获可能因此而引发的异常,但我不知道该在哪里做.

根据我的阅读,我应该在UI层中进行,但在这种情况下,我不确定如何确保与数据库的连接已关闭.是否有人能够澄清如何做到这一点？此外,如果有人知道我在哪里可以找到一个示例3层Web应用程序,该应用程序遵循最佳实践,也会很棒.

谢谢

Answer 1

没有简单的答案或模式可以确保成功.就像您的验证策略一样,您的确切异常处理策略特定于您的具体情况,并且通常需要在时间和全面性之间进行权衡.我们可以给出一些好的建议:

• 永远不要隐藏堆栈跟踪; 不要使用"Rethrow",除非为了安全起见,你想要隐藏发生的事情.
• 不要觉得你到处都需要处理错误.默认情况下,在较低层中,让实际错误渗透到顶层也不错.UI/Controller是你必须真正决定如何应对出错的地方.
• 在任何时候,如果出现问题,你自己究竟想要发生什么.通常情况下,你不会想到任何更好的事情,只是让它上升到顶层甚至是客户端机器.(虽然在生产转向冗长的报告中.)如果是这种情况,那就放手吧.
• 确保处置非托管资源(任何实现IDisposable的东西.)您的数据访问就是一个很好的例子.(A)在Finally块中调用(特别是)连接,命令,datareader等的.Dispose(),或者(B)使用Using Syntax/Pattern确保正确的Disposing发生.
• 寻找可能出现错误的地方,以及可以查找某些错误的位置,做出反应(通过重试,等待第二次重试,以不同的方式尝试该操作等),然后希望成功.您的大部分异常处理都是为了取得成功,而不仅仅是报告失败.
• 在数据层中,您必须考虑在多步骤过程中出现问题时该怎么做.你可以让实际的错误渗透,但是这个层必须在发生错误后处理整理过程.您有时希望使用交易.
• 在异步情况下(由于多线程或(B.)因为业务逻辑在"任务机器"上单独处理并且稍后执行),因此您尤其需要制定记录错误的计划.
• 我宁愿在应用程序的25%中看到"错误处理代码"而不是100%.100%表示您可能希望它看起来和感觉您有错误处理.25%表示您花时间处理真正需要处理的异常.