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

SE

「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が普及していった後に重要になるのは「《論理》を《表現》に提供する窓口を整備する」こと、さらに言えば「ビュー側のアーキテクチャを定義する」ことではないのかなぁと思います。

いつも括弧が多いなぁ。

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

SE

前項では考えを述べたので、本項では結論のない経験談をば。

現在私が所属しているプロジェクトでは、ビューとしてJSPを使用していますが、このとき規約として

  • スクリプトレットは使用禁止
  • アクションは使用禁止
  • pageディレクティブと規定のtaglibディレクティブ以外のディレクティブは使用禁止
  • 規定されたもの以外のカスタムタグは使用禁止

というものを規定しています。

かなり原理主義的な規約ですが、ほとんどテンプレートのような形で実装されるため、ビュー部分の見通しが良くなりました（結果、モデル部分の見通しも良くなります）。
「JSPでそんなことするんだったらVelocityみたいなテンプレートエンジン使えばいいじゃん」っていう向きもあるでしょうが、そこら辺はプロジェクト（というか大人）の事情で「あくまでもJSP」ということになっています。

ただ、プロジェクトの事情で仕方なく選択したJSPなのですが、実際に上記の方針で開発してみると、カスタムタグはビューとモデルの接合機構として案外エレガントなのではないかと思います（元々それを目的に作られた機構だから当たり前か）。
例えば、「モデル側に整数9桁／小数4桁で保持されているデータがあり、ページよって表示する小数桁を2桁とか4桁に変更したい」なんてときには「モデル側では生のデータをそのまま設定し、カスタムタグの属性で小数部の表現方法を切り替える」ということができます（もちろんJSP側はその属性の設定のみを行ない、実際の編集はデータに従属したフォーマッタに委譲します）。
これがVelocityであった場合、もう少しビュー側の作り込みが必要になります。
フロントエンドの変化に耐えられるようにするため、本来であればカスタムタグに相当する箇所をプロジェクトで作成することになるのですが、カスタムタグの存在によって、実際に必要になるときまでその開発を先送り出来ます（これは「アーキテクチャがカスタムタグに依存している」というのとは異なります）。

上記プロジェクトを進めていく過程で思ったのは、ビューの責務である「データのフォーマット」と「出力の構造へのマージ」のうち、後者についてはテンプレートエンジンでほぼ用が足りるのではないかということと、前者については存外面倒くさいということです。

データというのは、「クライアント上で表現されたデータ」「アプリケーションプログラム内で保持されたデータ」「DBに格納されたデータ」といったシステム的な都合や、「法定帳票上の評価単価」「照合帳票上の評価単価」とか「日本語表現」「アラビア語表現」といったビジネス的な都合で姿が変わります。
しかも、それぞれが実装上では必ずしもone-to-one ontoにはなりません。

結局、「ビュー側のアーキテクチャを定義する」というのは、その中でも「変化するデータの様相を管理するためのアーキテクチャを定義する」というのが大きな部分を占めるのかもしれません。
……ん？なんだか、ビューなのかモデルなのか良くわからないところに入り込んでしまった気がします。
うーん。