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

SE

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

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

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

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

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

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

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

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

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