当前位置：文江博客话题详情

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

发布于 2024-08-19 09:15:32 字数 318 浏览 6 评论 0原文

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

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

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

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

谢谢

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

梦一生花开无言 2024-08-26 09:15:32

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

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

There are no easy answers or patterns that will ensure success. Just like your validation strategy, your exact exception-handling strategy is specific to your exact situation, and is often a trade-off between time and comprehensiveness. There is some good advice we can give though:

Don't ever hide the stack-trace; don't ever use "Rethrow" unless for security purposes you want to hide what happened.
Don't feel you need error handling everywhere. By default, in your lower tiers, letting the actual error percolate up to the top tier is not bad. The UI/Controller is where you have to really decide how to react to something going wrong.
At every point, as yourself what exactly you want to happen if something goes wrong. Often, you won't be able to think of anything better than to just let it go up to the top layer or even to the client machine. (though in production turn of verbose reporting.) If this is the case, just let it go.
Make sure you dispose of unmanaged resources (Anything that implements IDisposable.) Your data access is a great example. Either (A) Call .Dispose() for your (especially) connection, command, datareader etc. in the Finally block, or (B) use the Using Syntax/Pattern which makes sure that proper Disposing happens.
Look for places where errors are likely and where you can look for certain errors, react (by retrying, waiting a second retrying, trying that action a different way, etc.) and then hopefully succeed. Much of your exception handling is to make success happen, not just to report failures well.
In data layer, you must consider what to do if something goes wrong in the middle of a multi-step process. You can let the actual error percolate up, but this layer must handle tidying things up after an error. You'll sometimes want to use transactions.
In an asynchronous situation (either (A.) because of multiple threads or (B.) because business logic is processes separately on "task machines" and such and acted upon later), you in particular need to have a plan for logging errors.
I'd rather see "error handling code" in 25% of your app than 100%. 100% means you probably wanted it to look and feel like you have error handling. 25% means you spent time handling exceptions where they really needed to be handled.

回复收藏 0 原文

最笨的告白 2024-08-26 09:15:32

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

-克里普

回复收藏 0 原文

执手闯天涯 2024-08-26 09:15:32

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

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

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

如果您需要在释放异常之前“清理”内容，则始终可以使用 finally 块进行清理。您不必 catch 才能使用 finally 块。

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