Spring MVC-REST服务中的bean列表上的@Valid

Spring MVC-REST服务中的bean列表上的@Valid

@Valid

是JSR-303批注，JSR-303适用于JavaBeans的验证。A

java.util.List

不是JavaBean（根据JavaBean的官方描述），因此不能使用兼容JSR-303的验证器直接对其进行验证。这有两个观察结果支持。

第3.1.3中的JSR-303规范说：

除了支持实例验证之外，还支持对象图的验证。图形验证的结果作为一组统一的约束违规返回。考虑以下情况：bean X包含类型Y的字段。通过使用@Valid注释对字段Y进行注释，当X被验证时，验证器将验证Y（及其属性）。在运行时确定类型Y声明的字段（子类，实现）中包含的值的确切类型Z。使用Z的约束定义。这样可以确保标记为@Valid的关联具有正确的多态行为。

集合值，数组值和通常可迭代的字段和属性也可以使用@Valid注释修饰。这将使迭代器的内容得到验证。支持任何实现java.lang.Iterable的对象。

我已经用粗体标记了重要的信息。本部分意味着，要验证集合类型，必须将其封装在Bean中（由表示

Consider the situation where bean X contains a field of type Y

）；此外，集合不能直接验证（由表示

Collection-valued, array-valued and generally Iterable fields and properties may also be decorated

，重点是字段和属性）。

实际的JSR-303实现

我有一个示例应用程序，它使用Hibernate Validator和Apache Beans Validator来测试集合验证。如果以

mvn clean test -Phibernate

（使用Hibernate Validator）和

mvn clean test -Papache

（用于Beans Validator）对此示例运行测试，则两者都拒绝直接验证集合，这似乎与规范相符。由于Hibernate Validator是JSR-303的参考实现，因此该示例进一步证明了必须对集合进行封装才能进行验证。

清除这些内容后，我要说的还有一个设计问题，就是试图以问题所示的方式将集合直接传递给控制器​​方法。即使验证直接在集合上进行，控制器方法也将无法使用其他不能直接映射到集合的数据表示形式，例如自定义XML，SOAP，ATOM，EDI，Google协议缓冲区等。为了支持这些表示，控制器必须接受并返回对象实例。那将需要以任何方式将集合封装在对象实例中。因此，List如其他答案所建议的那样，最好将另一个对象包装在内部。