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

Question

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

我试图在网上浏览一些例子，但找不到任何内容，直到整个项目显示所有内容如何链接在一起。

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

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

感谢

Answer 1

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

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

Answer 2

只是可以引导您思考的一个侧面点：如果您有任何类型的卷可能导致并发问题（死锁），您将希望您的应用程序检测到该特定的SQL错误并重试该操作（例如，事务）。这就要求在数据层或业务层进行一些异常处理。

-Krip

Answer 3

我相信在最后一个负责任的时刻处理异常的最佳做法。这通常意味着在UI级别（即MVC应用程序中的Controller或传统asp.net应用程序中的代码隐藏）。它处于这个高级别，你的代码“知道”用户在询问什么，以及如果某些东西不起作用，需要做些什么。

处理调用堆栈中较低的异常通常会导致调用代码无法正常处理异常情况。

在您的数据层中，您将使用标准模式（例如，using statement用于IDisposables，例如SqlConnection），您知道的文档异常可能会发生（请勿执行此操作）对于内存不足或其他罕见情况），然后让它们在调用堆栈时向上流动。在可能必须由调用者处理许多异常的情况下，您可能希望捕获这些异常并将它们包装在单个异常类型中。

如果您需要在放弃例外之前“清理”内容，您可以随时使用finally block进行清理。您无需catch即可使用finally阻止。

我不知道有哪些小网站的例子旨在强调正确的异常处理，抱歉。

Answer 4

这不是您问题的具体答案，但如果您对最佳实践感兴趣，我会看一下Microsoft模式和实践：

Application Architecture Guide

Web Applications Guides