MVCモデルにおいてはモデル(アクションが定義されたBeanなどのクラス)と
ビュー(jspファイルなど)の結びつきを何らかの形で表現する必要があります。
例えばstrutsの場合であれば、struts-config.xmlに下記のように書くかと思います。
MVCに限らず、各種の設定情報をxmlに記述するというのはサーバーサイド
のプログラミングでは一般的な作法ですが、以下のような問題が出てきます。
1. 本来のプログラミングに加えて、xml設定ファイルの作成＆編集が必要になる。
特に初学の際にはフレームワークの使い方を覚えるのが大変になってしまう。
2. プログラムコードとxml設定ファイルのいずれか一方を見ても、全体的な画面
遷移を把握することが難しい。流れを掴むためには双方を交互に見比べるという
作業が必要になり、それが開発者に負担となる。
実際、上記のstruts-config.xmlを見ればわかりますようにaction要素だけでも
実に様々な属性や子要素を持っています。また、これだけ眺めても全体的な流れ
を掴むことはできません。
こうした問題に応えるためのフレームワークが登場してきています。
まず1.についてですが、「だったらxml設定ファイルなんて書かなければいい」
という発想が出てきます。それを実現しているものの一つが「Mojavi」です。
(http://mojavi.org/)←今はちょっと繋がらないみたいです...
PHP向けのフレームワークということでは「Phrame」の方が有名なようですが
設計思想という観点ではPhrameはstrutsとほぼ同じスタンスのようです。
Mojaviが特徴的なのはモデルとビューの関連付けをxml設定ファイルではなく
ファイルの命名規則によって関連付けを実現しているという点です。
（もちろん他にもフィルターやアクションをチェーンとして連結するなど、
便利そうな仕組みがいろいろと用意されています）
命名規則は下記のようになっています。アクションの命名規則は
webapp/modules/[モジュール名]/actions/[アクション名]Action.class.php
となっており、このアクションに対応するビューの命名規則は
webapp/modules/[モジュール名]/views/[アクション名][ビュークラス名].class.php
となります。
さらに、[ビュークラス名]はアクションが返す定義済みの定数と結びついており、
「VIEW_ALERT」「VIEW_ERROR」「VIEW_INDEX」「VIEW_INPUT」「VIEW_NONE」
「VIEW_SUCCESS」といった定数が用意されています。strutsのfoward要素やJSF
のLogical Outcomeに指定する出力値をどうやって決めるか悩むことが多いかと
思いますが、Mojaviの場合にはそうした余計な悩みも軽減されているということ
ですね(^^)
ちなみにPHPのもう一つのフレームワークである「Ethna」にも似たような命名規則
による関連付けの機能があるみたいです。(http://ethna.jp/ethna.html)
「Mojavi」は「Smarty」などの他の便利な仕組みとの親和性も高いようで、PHPに
おけるフレームワークという意味では今後普及しそうな予感がしています。
(「Mojavi」は「モハビ」と読むそうです)
この命名規則による関連付けによってxml設定ファイルを作成する手間をなくすと
いう考え方はここ最近のトレンドの一つであるように感じています。Seasarプロ
ジェクトの中の「S2Dao」(http://homepage3.nifty.com/seasar/s2dao.html)
などがその例です。strutsやHibernateというのはWEBアプリケーション開発に
おける代表的なフレームワークですが、いずれも使いこなすためにはxml設定
ファイルに精通する必要があります。(もちろん、XDocletなど各種ツールは存在
しますが、設定ファイルに関する知識がゼロで済むということではありません)
「Mojavi」はモデルとビューの関連付けをxml設定ファイルに過度に依存した
MVCフレームワークへのアンチテーゼであり、「S2Dao」は同じくxml設定ファイル
への依存が強い各種のORマッピングツールへのアンチテーゼなのかも知れません。
あるいはJ2SE5.0で加えられたアノテーションの仕組みなどを用いて、ソースコード
内にxml設定ファイルの内容を包含してしまうというスタンスもあるかと思います。
2.の問題もなかなか厄介です。JSFではstrutsと違い、画面のナビゲーション定義
を下記のようにアクションマッピングとは切り離して定義ができますが、(というか
JSFの場合はイベントドリブンなのでアクションのハンドリングはUIコンポーネント
の守備範囲です)画面の流れが分岐するような場合には状況が掴みづらくなります。
さらに一部のビュー遷移の箇所を切り出して再利用することは非常に困難です。
/start.jsp
detail
/detail.jsp
list
/list.jsp
こうしたことを解決するのが「Spring Framework」のサブセットとして提供が
予定されている「Spring Web Flow」です。(http://www.springframework.org/)
「Spring Web Flow」ではモデルとビューの関連付けや画面遷移をxml設定ファイル
に記述する点は既存のフレームワークと同じですが、xml設定ファイルの記述能力が
格段に向上しています。イメージ的にはUMLのアクティビティ図に近いような感じです。
TheServerside.COMで紹介されているように条件分岐も表現できるので、xml設定
ファイルを眺めるだけで全体の画面遷移を掴むことができます。
http://www.theserverside.com/articles/article.tss?l=SpringWebFlow
さらにstrutsやJSFを含む既存のフレームワークとの併用も可能で、定義した部品
は再利用が可能であるとのことです。まだ開発中ですが、「Spring Framework」
はここ最近日本国内でも取り上げられる機会も増えてきて勢いを感じます。その波
に乗る形で「Spring Web Flow」も普及してくるかも知れません。
こう考えてみると、「xml設定ファイルをなくし、プログラムコードに情報を集約
する」ことと、「画面遷移の一覧性と部分的なモデル＆ビュー集合の再利用性を
高める」ということを同時に実現するのはなかなか難しいのかも知れません。
結局どちらが良い/悪いということではなく、場面に応じて使い分けることになる
かと思います。命名規則を用いるスタンスはラーニングカーブを緩くし、個々の
プログラマの負担を軽減できることが最も大きなメリットでしょう。そう考えると
比較的中小規模で開発期間も短いケースで多用されるPHPのフレームワークである
「Mojavi」がこのスタンスを取っていることは自然なことです。一方で、J2EEの
世界では規模もある程度大きくなり、開発をする人と配備(デプロイ)をする人が
別になることもあるので、プログラムコードとは別に設定情報を集中的に管理する
仕組みが必要になってきます。大規模開発で効率を上げようとすれば、再利用性も
求められてきます。「Spring Web Flow」が生まれた背景にはそうした事情がある
ようにも思われます。
「MVCフレームワーク」という言葉が登場してからずいぶん経ちますが、現場の様々
なニーズに応えるという意味ではまだまだ進化が続く分野なのかなぁと思います。
