N层/ N层错误处理设计

Out团队正在构建一个可处理大量数据库和网络方法的N层应用程序。N层/ N层错误处理设计

基本上，我们设计了下面的层（从下到上）：

数据层：可以是Oracle或SQL（基本上是一个EF实体和上下文自动生成的使用数据库前）持久性层：处理数据层。我们有一个Oracle的持久层和另一个SQL层，它们之间有一些细微的变化（我们希望重申，将来有一个代码 - 接受想法）。业务层：这是处理特定的应用程序逻辑。

在此之上，我们可以有一个表示层（ASP.NET应用程序），一个直接调用业务功能的API，一个允许来自网络的业务请求的网络代理等等。

我们对错误处理机制有怀疑。我们决定所有的异常都是在业务层面上进行威胁，所以这是唯一一个有try/catch语句的地方。

我们的观点是我们不希望应用程序用户摆脱异常，但他们需要知道操作的状态。我们创建了一个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属性取决于应用程序的文化之前设置的本地化。

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

我们的工作人员正在考虑： a）在每次通话中使用元组。这不是推荐的方式。 b）抛出一个期望：不符合我们的架构。 c）在每次通话中使用ReturnStatus：考虑一个选项，甚至看起来老式。 d）将最后一个错误对象保存在某个地方，因此调用可以直接返回数据，用户可以调用lastactionstatus来获取此错误。我们的观点是：我们不知道在哪里存储最后的错误数据。在单身课上？

解决方案必须在所有业务方法之间保持一致。

对于最佳方法以及如何实现它，你会推荐什么？

来源

2013-08-24 Mendes

你做错了什么，而是看这个信息我得到它从微软企业库

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

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

替换处理程序。这个异常处理程序将一个异常替换为另一个异常。

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

故障合同异常处理程序。此异常处理程序专用于Windows Communication Foundation（WCF）服务边界，并从异常中生成新的故障合同。

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

我建议你使用Microsft Enterprise库。

Exception Handling in MEL 6.0

来源

2013-08-24 12:43:13

我们知道如何处理异常。这不是问题或问题。我们的问题是关于我们应该在用户层使用什么方法，因为我们不想传播异常处理程序。 – Mendes

我想知道是否这个gona工作你必须检查stauts每次这是一个非常古老的编程风格和最C和C++程序员仍然在嵌入式系统中使用它。我强烈建议你在你的架构中重新设置异常处理，否则你将永远无法获得这个系统的稳定性，或者我错过了一些东西，因为我没有软件中的源代码和整个错误处理工作流程，只是感觉。 –

同意。返回码只是感觉不对。我没有发现让层之间出现异常的问题。你遇到了返回代码的问题 - 因为你返回一个代码，你不能返回数据，所以你的方法需要你'out'或'ref'。让异常发生并在最后一层适当地处理它们。 –

Here您可以查看异常抛出，also一些性能问题要考虑的一些准则。

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

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

希望它能帮助！

来源

2015-02-17 09:54:19 Juanito

N层/ N层错误处理设计

回答

相关问题