N层/N层错误处理设计

Out团队正在构建一个N层应用程序，该应用程序将处理许多数据库和网络方法。

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

数据层：可以是Oracle或SQL（基本上是EF实体和使用Database First自动生成的上下文）持久层：处理数据层。我们有一个用于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来获取此错误。我们的观点是：我们不知道将最后的错误数据存储在哪里。在单例类上？

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

你认为最好的方法是什么以及如何实现它。