Spring Roo始めました。 その3

今日は、JSR303 (Bean Validation)の話

制約を設ける

セレブが入会する会員制クラブをつくろう！としています。

そこで、メンバーテーブルを作ります。



基本的な制約をここでかけています。

• 名前
• not null / 最低2文字 / 最大40文字
• 姓名
• not null / 最低3文字 / 最大40文字
• 年齢
• 最低20 / not null
• 収入
• not null
• 会員登録日
• 過去

出来上がったMembershipクラスは次のようなコードになっています。



この段階で自動生成されたテストを流します。



自動生成されたテストのデータというのは、Spring Rooが出力したテストデータ生成用のクラスMembershipDataOnDemandクラスによって作成されます。

ビジネス的な制約の導入

ところでセレブがくる会員制クラブですので、若いヤンキーニーチャンを入会させたくありません。

そこで、30歳未満の人には高めの収入(100,000ドル以上)を持っていることを制約条件に加えようと思います。

まず、テストに上の条件のユーザーの制約を書いてみます。



テストを流します。



30歳未満で収入の低い人が入会できないことを確認するテストyoungMemberCannotBeAppliedが落ちていることがわかります。

では、この条件を実装していきます。

ここで使うのがJSR303のBean Validation APIの@AssertTrueです。

@AssertTrueは指定したフィールドまたはメソッドがtrueを返すことを強制する制約です。

これを用いて条件を実装します。



では確認のためにテストを流しましょう。



追加したテストの方は通ったようですが、あれれ、自動生成されたテストは軒並み落ちていますね。

まあ、勝手に追加した条件なのでSpring Rooの方では検知できないのでしょう。よく考えればそうですね。

git

んで、よく見てみると、モデルに変更を加えた後になぜかAspectJのコードが変化しているようです。



何が変わったのでしょうか？





40文字以上だったら40文字に直してくれてたコードが、直してくれなくなっていますね。

また、年齢が20未満だったら20に直してくれていたコードが直してくれなくなっていますね。

日付についても現在より10,000,000Lだけ前に修正してくれていたコードが現在時間+αになるように変更されています。

Spring Roo君はなんてことをしてくれるんだ！

Push in

こうなったら、AspectJのコードをJavaの方にPush Inして調整する必要があるようです。

変更されてしまったメソッドにカーソルを当てた状態で、IntelliJ IDEAのRefactorメニューからPush ITDs Inを選択します。

(eclipse…知らん…)

その後、MembershipDataOnDemand.javaのPush Inされたメソッドをテストが通る(と言うよりはビジネス的に問題のないデータが提供される)ように修正します。



では再度テストを実行してみます。



はい、通りました。

結論

はい、Spring RooのBean Validation API関連の作業について見てきました。

多少面倒なところはあるもののテストデータを自動で生成してくれたり、テストを自動で生成してくれているところは助かります。

ただ、複数のフィールドにまたがるビジネス上の制約についてはRooはアホなくらい鈍感ですね。

このあたりは慣れるしかなさそうです。