2

クライアントが利用できる API を定義します。クライアントはさまざまな手段で接続されます。それらの 1 つは Java-to-Java です。この特定のケースでは、問題が発生しています。明らかに、API は可能な限り実装から分離する必要があります。これをテストする機会はまだありませんが、ユーザー定義の検証はこのモデルを壊しませんか?

APIサーバー側の実装でSpring @Validatedを介して検証を有効にしています。サービス（API）への唯一の方法ではないため、これを @Controller クラスに入れたくありませんでした。

たとえば、次のメソッドがインターフェイスで定義されているとします。

SomeObject updateOperation( AnInputClass param) ...

その後、JSR-303 検証で注釈を付けても、分離することができます。@Constraint(validatedBy) 部分を持つ独自の注釈を作成し ます。この部分は検証の実装に結び付けられます。これの省略形は次のようになります。

SomeObject updateOperation ( @CheckInput AnInputClass param)... 
...where the annotation is defined as
...
@Constraint(validatedBy = CheckInputValidator.class)   // this is the coupling issue
public @interface CheckInput { ....

これはすべてサーバー側で行われるため、Java クライアントにこの CheckInputValidator クラスを持たせる必要はありません。ただし、オプションが表示されません。まず、私は API でバリデーションを行うのが好きです。何がバリデーションされるかをユーザーに伝えます。依存関係を壊して検証を実装に移すことができれば、許容できるトレードオフのように思えます。ただし、以下の例外が発生するため、行き詰まっているようです。誰でも助けることができますか？

javax.validation.ConstraintDeclarationException: Only the root method of an 
overridden method in an inheritance hierarchy may be annotated with parameter 
constraints, but there are parameter constraints defined at all of the 
following overridden methods
4

1 に答える 1

3

答えは自分で見つけた、もっと早く気づくべきだった！

インターフェイス/API レイヤーで「@Valid」アノテーションを使用するだけで済みました。次に、User Defined / Custom アノテーションの @Target アノテーションに「TYPE」が定義されていることを確認し、目的のクラスに @CheckInput アノテーションを適用すると、すべてが完全に機能します。

于 2012-09-27T21:33:46.623 に答える