我应该通过JSR 303/Bean验证处理多少逻辑？

Question

我有一个Play 2.0.1应用程序，并且刚刚通过弹簧数据联编程序获取表单处理的挂起，如described in the documentation。我的地方，我哈瓦形式，比方说，一个用户发送消息给其他用户，看起来像这样的地步：

public class MessageForm { 

    @NotNull @NotEmpty 
    public String message; 

    @NotNull 
    public User recipient; 

    // i know, no sender 
} 

我定制绑定可以确保用户，这是由他的身份证在代表HTML表单会正确序列化，并且在没有这样的用户存在时默认为空。

我正在考虑编写额外的验证，即i.E.确保用户通过表单传递的信息是用户试图发布信息的朋友。这基本上是一种@FriendsWithCurrentUser - 注释。

我知道如何做到这一点，我的问题是：这是个好主意吗？从模块的角度来看，这将是一个有点扎根于Web上下文的约束，所以我不想把它放在我的模型 - 包中。我有模糊的感觉，这可能不是JSR的意义，但我也认为这会大大减少我的控制器中的逻辑，并允许我重用类似的用户提交约束。

Answer 1

这是常见的问题。另一个类似的情况是必须与数据库交谈的验证。

从我的角度来看，问题是您多久会使用一次验证？如果它将在20个地方使用，我会写注释+验证器类，但如果在一个或两个地方使用此验证，则最好手动抛出ConstraintViolationException。然后我们仍然使用通用的验证机制，但我们不需要编写可疑的验证器类。有时候这也是性能问题：我们只是为了验证而查询数据库，而且这种查询经常在商业逻辑中重复。

权衡是从码相对于验证器，其混合的各种应用层的其余部分具有良好分离验证之间。

平时我比较喜欢，因为经常会出现相同的验证已经在别处用来编写单独的验证。如果没有独立的验证，我经常重复现有的验证码，因为总有一些东西做的，然后重构验证更重要......

Bean验证的想法是在应用单独的层，负责验证。该层不应该与模型混合使用，因为给定的模型可以通过许多不同的方式进行验证。

可能有一个模型和各种成套验证的 - 注释只是配置。有时，如果要将Model用于各种产品，最好放弃注释并使用基于XML的配置（这很容易理解和使用）。

所以不要把验证的模型包，为你的校验创建一个新的包，如果你想要去的方式。