7

我正在构建标准的 3 层 ASP.NET Web 应用程序，但我正在为在哪里做某些事情而苦苦挣扎——特别是处理异常。

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

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

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

谢谢

4

4 回答 4

6

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

  • 永远不要隐藏堆栈跟踪；除非出于安全目的您想隐藏发生的事情，否则永远不要使用“重新抛出”。
  • 不要觉得到处都需要错误处理。默认情况下，在您的较低层中，让实际错误渗透到顶层也不错。UI/Controller 是您必须真正决定如何应对出现问题的地方。
  • 在每一点上，如果出现问题，作为您自己，您究竟想要发生什么。通常，您将无法想出比让它上升到顶层甚至客户端计算机更好的方法。（尽管在详细报告的生产中。）如果是这种情况，那就放手吧。
  • 确保您处置非托管资源（任何实现 IDisposable 的资源。）您的数据访问就是一个很好的例子。( A )为您的（尤其是）连接、命令、数据读取器等在 finally块中调用.Dispose()，或者 ( B ) 使用确保正确处理发生的使用语法/模式。
  • 寻找可能出现错误的地方，以及您可以在哪里寻找某些错误，做出反应（通过重试、等待第二次重试、以不同的方式尝试该操作等），然后希望成功。您的大部分异常处理是为了让成功发生，而不仅仅是为了很好地报告失败。
  • 在数据层，您必须考虑如果在多步骤过程中出现问题该怎么办。你可以让实际的错误向上渗透，但是这一层必须在错误发生后处理整理。您有时会想要使用事务。
  • 在异步情况下（（A.）因为多线程或（B.）因为业务逻辑是在“任务机器”等上单独处理并稍后采取行动），您特别需要有一个记录错误的计划。
  • 我宁愿在 25% 的应用程序中看到“错误处理代码”，而不是 100%。100% 意味着您可能希望它看起来和感觉就像您有错误处理。25% 意味着您花时间处理真正需要处理的异常。
于 2010-01-26T15:30:42.967 回答
1

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

-克里普

于 2010-01-26T15:24:06.883 回答
1

我相信在最后负责任的时刻处理异常的最佳实践。这通常意味着在 UI 级别（即 MVC 应用程序中的控制器或传统 asp.net 应用程序中的代码隐藏）。在这个高层次上，您的代码“知道”用户在问什么，以及如果某些事情不起作用需要做什么。

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

在您的数据层中，您将使用标准模式（例如，用于 IDisposables 的using语句，例如 SqlConnection），记录您知道可能发生的异常（不要因为内存不足或其他罕见情况而这样做），然后让它们当他们这样做时，向上流动调用堆栈。在许多异常可能必须由调用者处理的情况下，您最多可能希望捕获这些异常并将它们包装在一个异常类型中。

如果你需要在让异常消失之前“清理”一些东西，你总是可以使用finally块来清理。你不必catch为了使用一个finally块。

我不知道任何旨在突出适当异常处理的小型网站示例，抱歉。

于 2010-01-26T15:24:20.457 回答
0

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

应用架构指南

网络应用指南

于 2010-01-26T16:21:59.870 回答