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

Question

我有一个Play 2.0.1应用程序，正在通过spring data binder掌握表单处理的窍门，如文档中所述。我有一个表单，假设一个用户给另一个用户发送消息，看起来像这样:

public class MessageForm {

  @NotNull @NotEmpty
  public String message;

  @NotNull
  public User recipient;

  // i know, no sender
}

我的自定义绑定器确保用户（由他的id以超文本标记语言-form表示）得到正确的序列化，并且当不存在这样的用户时默认为空。

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

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

Answer 1

这是常见的问题。另一种类似的情况是必须与数据库通信的验证。

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

权衡是在将验证与代码的其余部分很好地分开与混合各种应用程序层的验证器之间进行权衡。

通常我更喜欢编写单独的验证，因为在其他地方经常需要使用相同的验证。没有单独的验证器，我经常重复现有的验证代码，因为总是有一些更重要的事情要做，然后重构验证。。。

Bean验证的思想是在应用程序中有单独的层，负责验证。该层不应该与模型混合，因为一个给定的模型可以用许多不同的方式进行验证。

可能有一个模型和各种验证器集 - 注释只是配置。有时，如果 Model 要用于各种产品，那么最好放弃注释并使用基于 XML 的配置（它非常容易理解和使用）。

所以不要把验证器放在模型包中，为你的验证器创建一个新的包，如果你想这样做的话。