全てはAOPで - kunit’s diary

http://d.hatena.ne.jp/harux/20050619#p1

id:haruxさんの日記で勉強会に対する感想が書かれていて、「ビューやバリデーションまでフィルタにするのはやりすぎとも言えるのではないだろうか。」というご意見をいただいのでそれに対する（現時点の）私の考えを書いてみたい。

AOPということになると分けられるべきものは「Core Concern」と「Crosscutting Concern」になる。SeasarのAOPの説明で使われる訳語を借りると「顧客からの要求である機能」と「非機能要求」になる。（よく使われる「横断的関心事」という言葉はニュアンスを伝え切れてない訳語かもしれませんね・・・ログとかに直結してますし・・・）

Mapleで考える（メインで対応するといった方がいいかな？）「顧客からの要求である機能」とはActionから呼ばれるビジネスロジックであり、Actionはビジネスロジックを呼び出すFacadeとなる。それ以外のコンバートやバリデートや認証やビューなんかは全て「非機能要求」であると考えています。なので、フィルター（本来ならInterceptorとするべきだった）で実行するということに関してなんら問題ないと考えてます。（ま、全てWebWork2からのいただいた考えであるとはいえますが・・・）

ただし、ビューというのはどういう画面で業務を行えるか？ということでこれはこれで「顧客からの要求である機能」であるのだが、それはテンプレートエンジンというものが受け持つ責務なのではないかと考えています。（これはある意味もっとも重要な要求機能なのでよりいいテンプレートエンジンの出現を期待しているわけです）

そのテンプレートエンジンを好きに選べるというのは明らかにMapleの責務ではあるのでその辺りは強化していかないといけないですね。（Viewフィルターはやっぱり妥協せずSmartyViewフィルターにするべきだったと反省・・・）

私は画面遷移は結果としてツールが組み立てれればいいだけで、一つのコントローラや一つの設定ファイルをみるだけで把握できる必要はないと考えています。逆に画面遷移がそのコントローラーや一つの設定ファイルに支配されているのではなく、それぞれのモジュールが動作した結果こういう流れになるというものが理想かなと思っています。

あくまでもこれは私の現時点の考えであり、反論とかしていただくとものすごくうれしいです。

※追記こ難しく書きましたが要は「Actionでビジネスロジックが実行されるときには理想的なデータが理想的なシチュエーションで飛んできている」という状況を作るためにInterceptorを惜しげもなくはさむってことですね。