昨日の補足。
ちなみにURLとアクションクラスとのマッピングはGuiceのModule側で行っている。アクションクラスにつけるとパスの一覧をあとから見たいとか、不具合報告のあったURLからすぐにアクションを割り出したいとか言うのが多いと判断したため。NetBeansのJAX-RSサポートみたいにプロジェクトのツリーにパスが表示されるとかそれくらいまでプラグインで準備ができてあるのならクラスにアノテーションをつけてもかまわないと思う。
あとはコードの読めないXMLに集約しろやゴルァな人でも安心できるように一箇所で分かるようにしたかった。クラスが分かればIDEの機能ですぐにCTRL+クリック等でジャンプできるし、Genericsでフォームクラスも明示しており、キャストのミスも無いので問題ないかなと。アクションクラスの名前やパッケージ情報から自動的にアクションのURLが作られるというのは個人的には理解しにくい（書いてる本人は大丈夫だけど、他人が見たとき致命的に思える）と思ったので。
あとはやっぱりフォーム周りですね。なんでもStringで扱うというのが大嫌いなので。Stringのみで値を保持し、バリデーションで型を保障するのは非常にJavaらしくない。コンバータのためのバリデーションと本来のバリデーションが一緒になると非常に見にくいと思うのですよ。
入力値の種類にしても以下のようなものがあれば95％くらいはカバーできるはず。
- 文字列
- 整数
- 数値（小数点あり）
- 日付
毎回正規表現等のコンバートの保証用バリデーションを記述するのは馬鹿らしいすぎる。
バリデーションにしてもシンプルに書けるのならここもGuiceらしくコードで書いてしまったほうが良い。特に業務アプリはバリデーションは画面ごとにカスタマイズしたものが簡単に記述できるかどうかというのが一番のポイントになると思う。
例えば値の範囲のバリデーションをするとき専用にアノテーションとか特別な知識が必要としてなくても普通にif文で書けばいいやんとかそんな感じ。覚える量を極限まで減らしたのがGuice流だと思うのでそっちの方向でとんがりたい。アクションクラスのコードはStrutsまんまだけれども、値の使いやすさはJSFやWicketのようになるといいなとか。
もちろん、Stringそのままでも扱えるし、intだとコンバート失敗は0として扱うとかStrutsの部分はそのまま扱えるのが前提としての拡張ですが。あくまでも拡張。使わないといけない押し付けがましい拡張ではなくて、つかっても良いと判断できるようなレベルで控えめにおさえるというか。
