使用不同数据结构的ajax错误处理方法

Approach for ajax error handling with different data structures

本文关键字：ajax 错误 处理 方法 数据结构      更新时间：2023-09-26

我想使用两个或三个模块来显示错误，但我有许多不同的错误数据结构作为ajax的响应。应该避免为每个ajax错误回调或每个错误显示模块使用重复的if/else链。下面是我收到的一些错误响应的示例，它们是根据要显示给用户的属性来表示的:

500 Server Error: {
    ...
    Message: "An error has occurred.",
    ...
}
401 Login Error: {
    ...
    Reason: "Invalid login credentials.",
    ...
}
400 Bad Request on Put: {
    Errors: [
        {
            PropertyName: "EmailAddress",
            ErrorName: "Invalid email address."
        }
    ]
}

目前我正在考虑采取每个错误响应通过$httpProvider.interceptors在角(类似于ajaxSetup在jQuery?)，并强制一致的属性名称到每一个。我不知道这是不是一个糟糕的设计，但它肯定会使事情变得更容易。

解决这个问题的方法之一是使用两个概念:

  • 适配器模式
    • 工厂

单一责任原则:

显然，你可以把所有东西混在一起，让一些东西工作。在我的评论中，我建议使用Adaptor模式，但当我给出这个答案时，我意识到这还不够好。如果是这样，您的应用程序或仍然有一部分代码负责选择适配器，因此我们可以将其封装到一个工厂中，为您提供适当的适配器:

那么我们将有三个主要组件:

  • Application:负责应用逻辑，获取错误对象并将其传递给…
  • 工厂:负责分析错误对象并确定哪个适配器满足需求
  • 适配器:负责处理错误，并以独立于其内部格式的统一方式进行处理。

在JavaScript中可以是这样的:

function serviceResponse(error, response) {
  // assuming error could be all different shapes and sizes
  if (error) {
    adaptorFactory
      .getAdaptor(error)
      .process(error)    
  }
  // your valid response logic
}

未来的更改以适应新的错误格式

如果你有一个新的错误，你将不得不做两个更改，在工厂中创建一个新的适配器对象和一个新的if/else。但它的美妙之处在于，您根本不会触及应用程序逻辑。serviceResponse方法保持不变

同样，有很多好的解决方案，这只是一种方法。只要保留关键概念，您可以按照自己的意愿开发适配器和工厂。我的例子仅供说明之用。

相关文章：