Out 团队正在构建一个 N-Tier 应用程序,它将处理大量的数据库和网络方法。
基本上我们设计了以下层(从下到上):
数据层:可以是 Oracle 或 SQL(基本上是使用 Database First 自动生成的 EF 实体和上下文) 持久层:处理数据层。我们有一个用于 Oracle 的持久层和另一个用于 SQL 的层,它们之间有一些小的变化(我们希望将来重构它以拥有一个单一的代码 - 接受想法)。业务层:这是处理特定的应用程序逻辑。
在此之上,我们可以有一个表示层(ASP.NET App)、一个直接调用业务功能的 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 属性可根据之前设置的 App 文化进行本地化。
我们希望对业务层方法的每个调用都有一个 ReturnStatus。这可以登录到 ASP.NET 状态栏,返回到 API 或通过网络发送到其他应用程序。问题是我们的大多数业务类都返回数据,因此我们需要找到一种方法将状态和数据一起返回给消费参与者。
我们的员工正在考虑: a) 在每次调用时使用元组。这似乎不是推荐的方式。b) 抛出一个期望:不符合我们的架构。c) 在每次调用时使用 ReturnStatus:被认为是一种选择,即使看起来很老式。d) 在某处保存最后一个错误对象,以便调用可以直接返回数据,用户可以调用 lastactionstatus 来获取此错误。我们的观点是:我们不知道在哪里存储最后的错误数据。在单身课上?
解决方案必须在所有业务方法之间保持一致。
您会推荐什么最佳方法以及如何实施它。