java - REST 资源类中封装错误处理的良好模式或风格是什么？

Question

我已经多次遇到过这种模式。在伪代码中:


公共(public)类 BlahResource {
如果(这个错误)
构建响应(BAD_REQUEST)；
如果(那个错误)
构建响应(冲突)；
...
做一点事();
返回构建响应(成功)；
}


看起来还不错，但是当您有一百万个错误条件需要处理时，Resource 类中会积累太多的业务逻辑，并且噪音很快就会淹没代码实际执行的内容.

由于在资源中错误条件正在返回某些内容，因此从服务抛出的异常对我来说似乎不正确。封装返回条件和设置的不同组合的状态对象似乎有点矫枉过正。

在如何以逻辑、清晰的方式进行编码方面，我是否遗漏了一些明显的东西？可能是我缺少的一些功能性/ Guava /基于 lambda 的东西，或者只是一个常规的 OO 解决方案。

Answer 1

有一个完整的JSR-349 Bean Validation解决这些问题的规范

来自规范目标

Validating data is a common task that occurs throughout an application, from the presentation layer to the persistence layer. Often the same validation logic is implemented in each layer, proving to be time consuming and errorprone. To avoid duplication of these validations in each layer, developers often bundle validation logic directly into the domain model, cluttering domain classes with validation code that is, in fact, metadata about the class itself. This JSR defines a metadata model and API for JavaBean validation. The default metadata source is annotations, with the ability to override and extend the meta-data through the use of XML validation descriptors.

hibernate-validator是引用实现，但请注意，该实现不依赖于任何层(也不依赖于 Web 或持久层)

回到您的资源代码，这意味着，通过利用自定义约束，您的资源将类似于

public class BlahResource {
  @CheckBadRequest
  @CheckConflict
  private field
  ...
}

当验证失败时，错误将存储在 ConstraintViolation 内您可以通过Validator获取界面。这些是您应该构建错误处理机制的中心点，这也是一个伪

Set<Constraintviolation<Resource>> violations = validator.validate(Resource);