ビュー側のアーキテクチャ

「Tapestryはなぜ流行らないのか」
http://www.fuka.info.waseda.ac.jp/~k_ogino/study/fwzemi/b4/b4_04.htm

デザイナさんに優しいのは間違いなくTapestryです。Strutsは作り方次第ですけど、凝ったもの作ると確実に易しくないものが完成。

フロントエンドもプラットホームもいろいろあるでしょう。一概にどれでって決めてかかるものでも無い。大事なのはビジネスロジックで今まではフロントエンドのコードに埋め込まれていたか、EJBもしくはライブラリとして作ってたところです。これをDIでPOJOになるだけで将来の技術潮流変化リスクに対する保険になるなあと。

上記はいずれもTapestryから出てきた話題ですが、それに関連してビューにも言及されていますので、今回はTapestryとは別にビューの話をば。なお、本稿では「ビュー」を「外部への出力インターフェース」という意味で使用しています。

さて、過去の日記の「ビューにおける《分岐処理》」で「ビューから《分岐処理》という制御構文を排除するべき」であることを主張しましたが、その根底には「表現と論理の分離」への指向があります。
さらに、この「表現と論理の分離」の背後には「変化し易い《表現》から変化し難い《論理》を切り離し、《表現》に左右されずに《論理》を使い回したい（あるいは《表現》の変化に対応するためのコストを下げたい）」という欲求があります。
この欲求自身に注目した場合、「《論理》を《表現》から侵されないようにする」こともさることながら、「《論理》を《表現》に提供する窓口を整備する」ということが重要になってくるのだと思います。
これは単に「インターフェースを定義する」というだけに留まらず、より《論理》と外部との関係を意識した「ビュー側のアーキテクチャを定義する」ことが必要になるのではないかと思います。

POJOというのは「《論理》を《表現》から侵されないようにする」ことに対して非常に有用ではありますが、「《論理》を《表現》に提供する窓口を整備する」ことに対してはいささか物足りない感があります……というよりも、これはPOJOの範囲外の話であるといえます。
今後、POJOが普及していった後に重要になるのは「《論理》を《表現》に提供する窓口を整備する」こと、さらに言えば「ビュー側のアーキテクチャを定義する」ことではないのかなぁと思います。

いつも括弧が多いなぁ。