DAOはアスペクト？

Java AOP Seasar

アスペクト続きでもう一つ．
先週EA1がリリースされたS2Dao．恥ずかしながら私はまだ全然触っていないのですが，ドキュメントを見ただけでゾクゾクするすごさがあります．
なにがすごいって，DAOの interface さえ用意すれば，実装する必要がないって事．かなりのインパクトがあります．
それを実現しているのがアスペクト．なので，diconファイルに

<component class="foo.FooDao">
    <aspect>
        <component class="org.seasar.dao.interceptors.S2DaoInterceptor"/>
    </aspect>
</component>

と書いてあげるだけで，introductionなアスペクトがよきにはかってくれるということらしいです．すばらしい．


間違いなく素晴らしいんですが．．． ちょっと疑問を感じないではありません．
これは本当にアスペクトで実装すべきなのでしょうか？ データアクセスはcross-cutting concernなのでしょうか？
間違ってる！ といいきるだけの根拠は全然ないのですが，直感としては違うんじゃないかという気がしてしょうがないです．
実際の所，S2Daoで必要だったのは本来のAOP(っていうのがどういうものか理解できているわけではありませんが)ではなく，DynamicなProgrammingだったのではないでしょうか．そして，S2でそれを実現するほとんど唯一の手段がAOPだったということなのかな，と推測してみました．
もし，SpringでS2Daoに相当するものを実装するとしたら，FactoryBean を使ってプロパティで指定された interface の プロキシを作って返す，というやり方でも同等なものを作れる気がします．DAOに関しては，このやり方の方が違和感を感じないというのが正直なところ．
もっとも，FactoryBean みたいなものを導入してコンテナ本体が複雑になるくらいなら，さくっとAOPで作った方がいいよね，というのも正しいとは思いますけれど．
なんとなく，アスペクトの乱用を助長することにつながらないか心配してしまいました．
S2Daoにけちをつけたいわけではないので，そこのところよろしくです〜．


03:20 追記
よく考えてみれば，ドメインオブジェクトにとってのデータアクセスは cross-cutting concern ですね．
そういう意味では，タイトルの「DAOはアスペクト？」は true でしょう．
でもでも，今回の話はそれとはちょっと違うような．DAOにとってのデータアクセスは cross-cutting concern なのか？ という感じでしょうか．それなら false と思われ．
それで結局何が言いたいかというと，AOPの適用範囲を考えたいということ．
AOPの適用例として，既存のソースに手を入れることなく振る舞いを変えるとかっていうのもあったりしますが，そういうのも含めてAOPの使い方として疑問を感じることがままあります．
かつてOOPで is a でもないのにちょっとメソッドを拝借したいがためにやたらと継承を使ったりということを見かけたわけですが，それと同じような感じ．
ま，こういうのは，ある程度使いすぎてみないと使うべきじゃなかったという判断が出来なかったりもするので，いろいろな使い方をとりあえずはやってみるというのがまずは重要かもしれません．
でも違和感は拭いがたい．．．


04:20 さらに追記
上での話題はS2Daoの使い手にはなんの関係もない話です．念のため．
仮に(あくまでも仮に，ですよ)S2Daoが Spring の FactoryBean みたいなやり方だったとしても，使い方は全然変わりません．
ちょっと怪しいけどdiconファイルは次みたいになるでしょう．

<component class="DaoFactoryBean">
    <arg>FooDao.class</arg>
</component>

コンテナは DaoFactoryBean が返す型(FooDao)を使ってautoBindingできるはずなので，気になるような違いは全くないと思われ．