0

如文档中所述，我有一个 Play 2.0.1 应用程序，并且正在通过 Spring Data binder 掌握表单处理的窍门。我到了我有一个表单的地步，假设一个用户向另一个用户发送一条消息，看起来像这样：

public class MessageForm {

  @NotNull @NotEmpty
  public String message;

  @NotNull
  public User recipient;

  // i know, no sender
}

我的自定义活页夹确保用户（在 HTML 表单中由他的 id 表示）得到正确序列化，并且在不存在此类用户时默认为 null。

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

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

4

1 回答 1

1

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

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

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

通常我更喜欢编写单独的验证，因为经常发生必须在其他地方使用相同的验证。如果没有单独的验证器，我经常复制现有的验证代码，因为总是有比重构验证更重要的事情要做......

Bean Validation 的想法是在应用程序中有单独的层，负责验证。该层不应与模型混合，因为可以通过多种不同方式验证给定模型。

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

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

于 2012-06-12T22:07:39.400 回答