0

私は Play 2.0.1 アプリを持っており、ドキュメントで説明されているように、 Spring データ バインダーを介してフォーム処理のコツをつかんでいます。私はフォームを持っているところまで来ました。ユーザーが別のユーザーに次のようなメッセージを送信するとしましょう:

public class MessageForm {

  @NotNull @NotEmpty
  public String message;

  @NotNull
  public User recipient;

  // i know, no sender
}

私のカスタム バインダーは、HTML フォームの ID で表されるユーザーが正しくシリアル化され、そのようなユーザーが存在しない場合はデフォルトで null になるようにします。

フォームを介して渡されたユーザーがメッセージを投稿しようとしているユーザーと友達であることを確認するための、追加の検証を書くことを考えています。これは基本的に一種の@FriendsWithCurrentUser注釈になります。

私はそれを行う方法を知っています。私の質問は次のとおりです。これは良い考えですか? モジュールの観点からは、これは Web コンテキストに根ざした制約になるため、モデル パッケージには入れたくありません。これは JSR の目的ではないかもしれないという漠然とした感じがありますが、これによりコントローラーのロジックが大幅に削減され、ユーザーの送信に対して同様の制約を再利用できるようになると思います。

4

1 に答える 1

1

それがよくある問題です。他の同様のケースは、データベースと通信する必要がある検証です。

私の観点からすると、問題はその検証をどのくらいの頻度で使用するかということです。20箇所使うものならアノテーション+バリデータークラスと書くのですが、このバリデーションが1箇所か2箇所なら手動でConstraintViolationExceptionを投げたほうがいいです。次に、一般的な検証メカニズムを引き続き使用しますが、疑わしい検証クラスを記述する必要はありません。これはパフォーマンスの問題でもある場合があります。検証のためだけにデータベースにクエリを実行し、そのクエリはビジネスロジックで繰り返されることがよくあります。

トレードオフは、コードの残りの部分から十分に分離された検証を持つことと、さまざまなアプリケーションレイヤーを混合しているバリデーターとの間です。

同じ検証を別の場所で使用しなければならないことがよくあるため、通常は別の検証を作成することを好みます。別のバリデーターがなければ、既存の検証コードを複製することがよくあります。これは、検証をリファクタリングするよりも重要なことが常にあるためです...

Bean Validation の考え方は、検証を担当するアプリケーション内に別のレイヤーを持つことです。特定のモデルはさまざまな方法で検証できるため、そのレイヤーをモデルと混合しないでください。

1 つのモデルとさまざまなバリデータのセットが存在する可能性があります。注釈は単なる構成です。Model がさまざまな製品で使用される場合は、アノテーションをまったくやめて、XML ベースの構成を使用する方がさらに良い場合があります (理解して使用するのは驚くほど簡単です)。

そのため、バリデーターをモデルパッケージに入れないでください。そのようにしたい場合は、バリデーター用の新しいパッケージを作成してください。

于 2012-06-12T22:07:39.400 に答える