asp.net中的异常处理

在我实现的所有此类解决方案中，常识通常指示您只需报告DAL中的错误。

通过事务性地执行任何数据库更改，您将确保执行回滚，并用您自己的异常来结束实际异常，声明发生了内部异常，因此没有进行任何更改。

然后在BLL中捕获异常，然后将其作为调用应用程序的自定义"BusinessProcessException"进一步抛出。BLL是可选的，因为它在自己的"盒子"里——可以说，有时它有自己的日志记录机制来记录与业务流程相关的异常。

无论它是否在BLL层记录，您仍然需要通知UI层(客户端应用程序(发生了异常，并通过完整的异常树进行记录。

UI层中的客户端应用程序代码可能有自己的日志，但这不是BLL使用的日志。

事件周期是这样的。。。

应用程序调用bll方法bll方法调用dal方法dal方法调用数据库上的存储过程存储过程错误引发(例如(sql异常dal抛出新的dal异常，sqlexception作为内部异常bll处理dal异常并记录dal失败如果bll方法中有一些事务元素被调用，那么bll会回滚其他调用。bll抛出新的bll框架内部异常is-dal异常应用程序处理bll异常，并从完整的异常树中决定如何处理用户体验。

这几乎就是.net的工作原理。

需要注意的事项：

如果我有一个更新调用失败的业务对象，那么该业务对象可能有几个作为该调用一部分更新的子对象。这些子对象可以从不同服务器上的多个dal端点组装而成，并且每个dal端点可能必须更新潜在的几个数据库的中的几个记录

因此，bll逻辑有一个事务，每个dal调用内部工作有1个事务，然后每个存储的proc调用中可能有1个。

net在后台所做的是以这样一种方式堆叠这些事务，即如果bll级别的事务失败并调用回滚，则它应该回滚所有子事务，然而在事务跨越系统且通常是网络的现实世界中，这可能是不可能的。

因此，您必须假设您所采取的操作可能会失败，并且如果继承的任何部分失败，并且进行调用的代码对此负责，则可以回滚。

这最终意味着你需要对所发生的事情进行全面的审计跟踪。作为一个bll开发人员，我会记录我的框架所做的一切，sql也有事务日志，所以在这方面简化了许多dal实现。

应用程序只有(对于asp.net(服务器日志或自定义选项。

我唯一建议的是，每个层都记录自己的活动，日志是分开的(例如，与ui相关的错误实际上不属于bll日志(