Validation 在服务层处理远程api验证错误

想象一下，有一个管理器类与远程服务对话，例如，与可以创建新的和更新现有用户配置文件的用户微服务对话。这个管理器类在代码中的任何地方都使用：在控制器和其他类中。在与远程服务对话之前，我们的manager类不知道提交的DTO是否有效。问题是：如果远程服务返回验证错误，下一步该怎么办？如何处理这些错误？我已经考虑过了，有一些选择：

• 验证失败时引发异常
• 将收集验证错误的错误对象传递给管理器
• 在管理器类中创建方法getLastErrors（）

也许还有其他更好的解决方案

p、 假设远程服务以JSON格式返回错误，不管它是JSON-RPC、SOAP还是REST微服务

如何处理来自远程服务的验证错误

在响应正文中返回相关的信息，以及尽可能多的必要信息（有时没有）

它是SOAP还是RESTful并不重要，想象一下JSON 返回响应

---

服务的类型将决定您的故障处理方法。对于SOAP服务，您应该返回一个。

，除非您想将服务错误转换为不同的内容，或者甚至想在客户端层处理它们以做出某些决定，否则通常服务错误以人类可读的方式格式化，显示在UI中，以让用户知道哪里出了问题

另一方面，如果没有UI，则应该有一个记录器。就像您在UI层中所做的那样，您可以格式化这些错误并将其记录到文件或任何其他存储方法中

此外，您可能想了解更多关于以下方面的信息：

在系统设计中，快速故障系统是指能够立即报告故障的系统 在其接口处，任何可能指示故障的条件。 快速故障系统通常设计为停止正常运行，而不是 而不是试图继续一个可能有缺陷的过程。这样的设计经常出现 在操作中的多个点检查系统的状态，以便 故障可以早期检测到。故障快速模块通过测试 负责处理错误，但不检测错误 系统的下一个最高级别

OP评论道：

---

如果从microservice返回验证错误，则是哪个manager 那上课该怎么办？抛出异常或将这些错误放入某些 这是什么课

关于这个问题，我得出了一些结论，整个流程应该通过一个专门的DTO，我称之为：

表示一个多用途的正交实体，该实体同时传输 调用操作的结果，以及 呼叫者需要一个状态、状态描述和关于实际事件的详细信息 整个行动的结果

这样，即使在多层体系结构中，每一层都可以向累积的结果中添加更多信息或做出决策

---

可能有人会认为您应该抛出异常，但我不认为一个被破坏的规则是一个异常，而是一个预期的用例。

什么是“服务类”？你是说服务消费者吗？这个服务是RESTful的吗？还是基于SOAP？我更新了我的问题，希望它变得更清晰。如果是SOAP还是RESTful并不重要，假设返回JSON响应感谢您的回答，但问题不在于此如果验证错误从microservice返回，那么manager类应该做什么？抛出异常或将这些错误放入其类中的某个字段？@SergeySmirnov我已更新以修复累积结果描述的链接