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转换器不使用类构造函数，而是通过Reflection注入值。

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

仅使用JSR303验证。 Imho，这是一个糟糕的选择。与这些对象一起使用的业务层也必须具有经过验证的对象，而不需要复杂的（比new更复杂的）JSR303验证触发。
使用JSR303 +手动验证。它将同时满足：应用程序层和业务层，但由于JSR303依赖关系及其注释，它使域对象变胖。

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

Answer 1

我对这两个模型进行了广泛的工作，我个人认为JSR 303 bean验证更令人愉快。我的意思是纯粹使用bean验证注释，没有手动验证代码。

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

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

在DDD对象

1 个答案: