RIA型アプリとMVC2モデルの関係性

いろいろバタバタしてしまい、ブログの更新が滞っているのはうまくない。
mezawa氏と「RIA型アプリとMVC2モデルの関係性」についてメイルのやり取りをした。
これは以前から議論になっている話題。

RIA型のアプリを頑張って作るという行為は、「頑張って画面を作る」という行為と同じ意味。
このブログでも取り上げたサンプルも、サーバーサイドの処理をいれる場合には、

Javascript（クライアントサイドのプログラム）<=> PHPプログラム(a) <=> PHPクラス（ロジック）(b)

という形式になっている。
これは、コントローラの在り処が、PHPプログラム(a)にあることを示唆している。

これをJavaEEに置き換えると、

Javascript（クライアントサイドのプログラム）<=> サーブレット(c) <=> Javaクラス（ロジック）(d)

となる。

MVC2パターンは、エンタープライズ・デザインパターンで一番有名なものの一つ。
数年前には、「一番有用なデザインパターン」といわれていた。

だが、上に挙げたフローを見ると、直感的に「MVC2パターンに合致しない！！」という雰囲気に襲われてしまう。
それは、MVC2パターンというデザイン・パターンが、処理の「責務」と同時に、「処理順序」を示唆するためと思う。
Strutsは、MVC2モデルの最も有名な処理系の一つだが、Strutsは（そう思われつつも）「処理順序」を規定するフレームワークであって、MVC2モデルそのものではない。

MVC2モデルを、本来的に「責務の分離」としてみれば、上のフローは「きちんとMVC2に従って書きなさいよ」、つまり「ちゃんと、表示系とコントローラ、ビジネスロジックを分離して書きなさいよ」という見方ができる。
この場合、コントローラーはサーブレット（c）になって、ビジネスロジックはクラス（d）となる。ただ、Viewの部分にscriptが挟まってしまうので、Viewを作っているという行為自体が不自然なものに感じてしまうのも事実である。

以前に軽く照会したDWRは(c)に該当（これまた有名な「フロントコントローラーパターン」に従っている）し、dwr.xmlで定義されるPOJOが（d）となる。

これと同じ混乱が、Mushupプログラムや、コンポジットプログラムのような形式のプログラムにも当てはまる。
RIA型のプログラムには、少なからずこの形式のものが存在する。
この場合の処理フローは、

Javascript（クライアントサイドのプログラム）(e) <=> サーブレット(f)
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　<=> システム外にあるAPI(g)

となるが、この場合、処理をコントロールする主体は（e)となる。
ビジネスロジックは、(f)や(g)である。
(e)がViewも兼ねているので分かりにくい。
こういった場合は、そもそも、MVC2モデルに基づくプログラムと考えずに、コンポーネントモデルに従うプログラムと解釈するのが適当だろう。

さて、RIA型のアプリケーションを作る場合、旧来の意味でのMVC2モデル（処理フローを含意したMVC2モデル）と、コンポーネントモデルの線引きをどうすればいいのか？

以下は、覚書程度のガイドライン。
まず、前提は「RIA型のプログラムは、基本的にコンポーネントモデルにしたがう」と考える。
そして、以下のケースについて、旧来の意味でのMVC2モデル（JavaEEで言えば、Strutsを使った実装）を行う。

画面を遷移させなくてはならない場合。
終了時の処理が存在する場合。
（２に近しいが）リクエストの処理順序や、パラメータの整合性からトランザクションを厳密に規定しなければならない場合。
処理性能・レスポンス性能的に、クライアントサイドに実装することに無理が生じる場合。

特に上りの処理(入力系）では、以前にログに書いた「擬Ajax」のようなニーズがしばしば存在する。これは、2の場合に該当する。
こういった場合には、無理をせずに同期的な処理をするのが無難であろう。