Seasar2勉強会 第２回 S2DaoとAOP編

社内の勉強会。今回はS2Daoとアスペクトのかけかたの話である。

S2Daoはいじらしい

生成系はテーブル見てレコードエンティティクラスとDaoクラスを自動生成してくれる仕組。テーブルにある項目は全部生成してしまう。Railsほどは直感的かつ簡潔ではないが、Javaという枠組の中で、かなり頑張ってる感じがする。なんだかいじらしい。こういういじらしいのを見ると無性に使ってみたくなるのだった。
実行系はアノテーションと組み合わせて、プロパティ名からWHERE句を生成する感じ。単純検索向きで、慣れると結構使えるかも知れない。あと、SQL直書きファイルをオブジェクトにマッピングすることも出来るようだ。SQLを無理矢理排除しようとしないところが良い割り切りで、ここはRailsより幾分バランス良いかも知れない。複合主キーも制限つきながら使える模様で、調べる価値ありそう。

アスペクトかけるところは面白い

インターセプタは、実行するメソッドをオブジェクトとして貰ってきて、織り込む処理の中の都合のいいタイミングで〜.proceed() して実行していた。こういうリフレクションがらみは本当に面白い、みていてワクワクする。ただし、アスペクトの動作定義自体はやっぱり面倒臭い。毎度の議論だが、この手の奴は定義が増えていったらバカにならんと思う。

やっぱり記述量（というより生成量）が多い

全体に自動生成が効くのだが、触りもしないプロパティまで丁寧に生成してくれるのは、Railsから見るとやはりうざったい。カスタマイズしてると、再生成で上書きが困ってしまう。Javaなんで、仕方ないことではあるが…。

でも、適用レンジは？

さて、Seasar2の適用レンジはどの辺なのだろう。TeedaやS2Daoのような自動生成／処理方法押しつけ系の仕組みは、道からはずれるとエラいことになりがちだ。Javaであることを除いて考えると、Railsと同じような適用レンジになってしまうのではないか。つまり、大規模とかクリティカルなエンタープライズは御免して、である。これは、この手の手法の共通の問題なのだろうか？
ちなみに、私のいるチームの開発では、おそらく全然問題にならない。そんな大規模なものはまずなくて、他に書ける奴がいれば、さっさとRailsを適用したい位なのだった。