java - 在 DDD 对象中混合 JSR 303 Bean 验证和手册(通过 Apache Commons)

Question

我们的家庭项目中的许多域对象需要字段验证，我们使用 commons-lang 来实现此目的。例如:

public class Position {
    private static final int LATITUDE_AMPLITUDE = 90;
    private static final int LONGITUDE_AMPLITUDE = 180;

    private Float latitude;
    private Float longitude;

    public Position(float latitude, float longitude) {
        Validate.inclusiveBetween(-LATITUDE_AMPLITUDE, LATITUDE_AMPLITUDE, latitude,
                "Latitude must be +- " + LATITUDE_AMPLITUDE);
        Validate.inclusiveBetween(-LONGITUDE_AMPLITUDE, LONGITUDE_AMPLITUDE, longitude,
                "Longtitude must be +- " + LATITUDE_AMPLITUDE);

        this.latitude = latitude;
        this.longitude = longitude;
    }
}

我们决定不使用 JSR 303，因为它将域对象与基础设施耦合在一起，并且需要外部干预来触发验证。

但是当我们开始实现 REST 端点时，我们再次面临验证问题，因为 json 转换器不使用类构造函数，而是通过反射注入(inject)值。

通过 JSR303 和 Jersey 的 @Valid 注解验证对象非常容易，但需要使用 JSR303 注解域对象。我们这里有一些选择:

1. 仅使用 JSR303 验证。恕我直言，这是一个糟糕的选择。与这些对象一起工作的业务层还必须具有经过验证的对象，而无需复杂(比 new 更复杂)的 JSR303 验证触发。
2. 使用 JSR303 + 手动验证。它将同时满足:应用程序层和业务层，但由于 JSR303 依赖性及其注释，它会使域对象变得臃肿。

您对此有何看法？混合 JSR303 和手动验证是好方法吗？

Answer 1

在广泛使用这两种模型之后，我个人发现 JSR 303 bean 验证使用起来更加愉快。我的意思是纯粹使用 bean 验证注释，没有手动验证代码。

Bean 验证注释将验证逻辑与域实体本身分离。我相信这是一件好事，因为它减少了域实体中的样板代码，并使它们更具可读性和可维护性。正如您所提到的，它确实需要您注释实体中的字段才能使用它。根据您现有代码库的大小，这项工作可能并不简单。

我的大部分经验都是与 Hibernate Validator 相关的。 ，我发现这是一个很好、快速的 JSR 303 实现。