N层/ N层错误处理设计

时间:2013-08-24 12:32:12

标签: c# asp.net architecture error-handling n-tier-architecture

Out团队正在构建一个N层应用程序,它将处理大量数据库和网络方法。

基本上我们设计了以下图层(从下到上):

数据层:可以是Oracle或SQL(基本上是使用Database First自动生成的EF实体和上下文) 持久层:处理数据层。我们有一个针对Oracle的持久层和另一个针对SQL的持久层,它们之间有一些小的变化(我们希望重构一下,以便将来只有一个代码 - 接受的想法)。 业务层:这是处理特定的应用程序逻辑。

上面我们可以有一个表示层(ASP.NET App),一个直接调用业务功能的API,一个允许来自网络的业务请求的网络代理等。

我们对错误处理机制有疑问。我们决定在业务层上对所有异常进行威胁,因此这是我尝试/捕获语句的唯一地方。

我们的观点是,我们不希望应用用户摆脱异常,但他们需要知道操作的状态。我们创建了一个类似于:

的ReturnStatus类
public class ReturnStatus
{
    public enum ReturnStatusTypes : int { Success, Failure, Unknown }

    public ReturnStatusTypes Status;
    public int MessageCode;
    public string Message;

    /// <summary>
    /// Class constructor
    /// </summary>
    public ReturnStatus()
    {
        Status = ReturnStatusTypes.Unknown;
        MessageCode = 0;
        Message = "";
    }

    /// <summary>
    /// Class constructor
    /// </summary>
    /// <param name="status">Status</param>
    /// <param name="message">Message</param>
    public ReturnStatus(ReturnStatusTypes status, int msgCode)
    {
        Status = status;
        MessageCode = msgCode;
        Message = ErrorMessages.ResourceManager.GetString("ErrorCode" + msgCode);
    }
}

Message属性是可本地化的,具体取决于之前设置的App culture。

我们希望每次调用Business层方法都有一个ReturnStatus。这可以记录到ASP.NET状态栏,返回到API或通过网络发送到其他应用程序。问题是我们的大多数业务类都返回数据,因此我们需要找到一种方法将状态和数据一起返回给消费者。

我们的员工正在考虑: a)在每次通话时使用元组。这看起来不是推荐的方式。 b)投掷:不符合我们的架构。 c)在每次通话时都使用ReturnStatus:被认为是一个选项,甚至看起来很老式。 d)在某处保留最后一个错误对象,因此调用可以直接返回数据,用户可以调用lastactionstatus来获取此错误。我们的观点是:我们不知道在哪里存储最后的错误数据。在单身人士班上?

所有业务方法之间的解决方案必须统一。

你会建议什么是最好的方法以及如何实现它。

2 个答案:

答案 0 :(得分:1)

你做错了什么,但看看这个信息,我从微软企业库

获取它

使用异常处理程序 异常处理应用程序块旨在支持应用程序组件中的catch语句中包含的典型代码。应用程序块不是在应用程序组件中的相同catch块中重复此代码(例如记录异常信息),而是允许开发人员将此逻辑封装为可重用的异常处理程序。异常处理程序是.NET类,它封装异常处理逻辑并实现名为IExceptionHandler的异常处理应用程序块接口。异常处理应用程序块包括四个异常处理程序:

换行处理程序。此异常处理程序将一个异常包装在另一个异常中。

替换处理程序。此异常处理程序将一个例外替换为另一个例外。

日志处理程序。此异常处理程序格式化异常信息,例如消息和堆栈跟踪。然后,日志记录处理程序将此信息提供给企业库日志记录应用程序块,以便可以发布它。

故障合同异常处理程序。此异常处理程序设计用于Windows Communication Foundation(WCF)服务边界,并从异常中生成新的Fault Contract。

非常重要的是,如果你有另一个进程,主线程也必须捕获所有异常,例如从设备读取并在主线程(UI)中进行错误消息的本地化。

我建议您使用Microsft Enterprise库。

Exception Handling in MEL 6.0

答案 1 :(得分:0)

Here您可以查看一些异常抛出指南,also要考虑一些性能问题。

我一直在使用Elmah来记录异常,现在已经有一段时间了,我完全推荐它。

Exception handling with Elmah可以给你一个提示,你可以如何使用它。

希望它有所帮助!

相关问题