2012-04-23 3 views
3

私は、データモデルとビジネスレイヤーが2つの異なるモジュールにあるプロジェクトを持っています。もちろん、ビジネスモジュールはモデルモジュールに依存しています。エンティティ検証はjava-validation-apiアノテーションによって実装されます。私は(別のエンティティタイプ間の関係が検証されるビジネス検証、)クロスエンティティの検証を実装する必要がありますどこクロスエンティティ検証を実装する場所は?

は、私は思ったんだけど。現在、以下のオプションがあります。

  1. カスタムjavax.validation.ConstraintValidatorsと関連付けられた注釈を作成します。問題は、バリデーターがビジネスサービスへのアクセスを必要とする、すなわち関連するエンティティを検索する必要があるが、モデルモジュールはビジネスモジュールへの依存性を持たないことである。
  2. ビジネスサービスの永続/マージメソッド(つまりインターセプタを使用)でエンティティ間の妥当性検証を実装します。これは可能ですが、エンティティの検証とのクロスエンティティの検証は分離されており、検証のための場所は1つだけです。望ましいオプション

?より良い提案はありますか?

おかげで、 セバスチャン

答えて

1

ビューアプローチ1のイデオロギー的な観点からは優れています。 Bean Validationはモデルのレベル(Model-View-Controller)で動作しており、Modelパーツがデータベースと通話しても何の問題もありません。たとえば、コードの重複を避けるために、サービスライヤーとモデルバリデータの両方で使用できるDAOを作成することができます。

インターセプタはまた何かを検証するには良い場所ですが、あなたは、フルパワーとビーン検証の自動性を使用することはできません。おそらく、モデルオブジェクトのvalidateメソッドを手で呼び出すか、必要なところでConstraintViolationExceptionをスローするなどの作業が必要になります。さらに、モデルにはおそらくいくつかのバリデーションが残っているので、あなたが指摘したように、バリデーションが行われている場所は1つ以上存在します。

私は必要なDBコードをレイヤーを分離するために移動し、オプション1に行きます。

+0

返信ありがとうございます。 –

+0

別のレイヤーにデータアクセスメソッドだけでなく、検証に必要な複雑な計算がある場合は、オプション2を使用するのがいいでしょうか?または他の? –

+0

モデルも複雑な計算をするのに適しています.1つは可能な限りMVCに固執したいと思えば、もっと良く見えます。明らかに、これらの計算がサービスレイヤーで実行されていて、オプション2を使用して他の場所に移動することは意味がありません。 –

関連する問題