RIA時代のプレゼンテーション層
id:da-yoshiさんの素晴らしいエントリを読んで呼応。
確かに私もRIAを使ったシステム開発がいよいよ本流になりつつあるなという気がしています。
その主流はFlex/JavaScript/Silverlightでしょう。
いまのところ、自分はFlexを一番にお奨めしていて、次にjQueryやExtJSを使ったJavaScript、
その次にSilverlight2をお奨めしています。この辺は個人・会社さんによって各々優先度つけるところです。
多分JSまわりは知れば知るほど、使い勝手がよくなって、もしかしたらFlexを
抜く可能性もあるかもなあとはちょっと思ってますが。
IDEサポートなどを考えるとFlexは今のところ一番楽だとおもう。
しかしRIAを使うと責務の分担が難しい。そう考えています。
よりいっそうクライアント側で出来ることが増えるため、明確な指針が無いと開発を
円滑にまわしていくのは難易度が高いといえます。
いくつかのポイントをあげると
- 業務ロジックの分離
- サーバサイドから取得するデータの粒度
- バリデーションをどこまでやるか
- クライアントサイドでの実装分離の方針
などが課題じゃないでしょうか。
で、上記を大きくまとめるひとつの観点として、
クライアントサイドのリソースを上手に活用することが重要だと自分は考えています。
例えば業務ロジックが分散してしまうと保守性を維持するのが大変になってしまいますが、
クライアントサイドのリソースを上手に使うという観点では、ここでRESTっぽくデータを
大きな粒度でとってきてView層で編集・加工をまかせてしまう
（=クライアントのリソースをふんだんに使う）方が望ましいかもしれません。
C10K問題への対応としては、データをなるべく大きく取得してサーバサイドにGET/POSTしにいく回数を
減らすのが有効かも。
またバリデーションは出来るだけクライアントサイドで済ませたいと自分は考えています。
これもリクエストするデータを極力減らし、クライアントサイドのリソースを
上手く使いましょうということです。全部サーバサイドに飛ばしてしまうと、結局サーバサイドの
リソースに頼ってしまうのでRIAを有効活用するならばクライアントサイドでなるべくリクエストを
飛ばさないようにするのが良いんじゃないかなあ。
ただし、これも実際の責務分担の中ではっきり良い線引きが出来ればよいですが、悩みどころですね。
特に単純なチェックであればいいですけど、存在チェックなどテーブル内との照合が入ると
途端にクライアントサイドだけで実現するのがややこしくなります。
線引きとして、テーブルを使うチェック以外はクライアントサイドに
もっていってしまうというのもありですが、それはそれでチェックの順番の保持や、
エラーメッセージリソースはいつとるのか・メッセージの国際化はどうするのか、といった問題は
あったりするので注意が必要です。（FlexだったらメッセージはMessageResource使うってところですね）
次に視点を少し変えて、ユーザの立場にたってみましょう。
ユーザからすればもともと何故RIAがクローズアップされてきたかを考えると、
インタラクションの重要性にたどり着くのじゃないかと思います。つまり使い勝手の良さがより重要視されている。
昔のクラサバの使い勝手かそれ以上を求めているんじゃないでしょうか。
操作性に不満のあるシステムは使われません。またユーザさんの業務効率化は激化の一途ですし、
なんとか使える程度の操作性ではなく、「効率的に使うことのできる操作性」が求められています。
このあたりが重要なんじゃないかなと思う次第です。
そこで、使い勝手の良さを実現する方法のひとつとして、なるべくクライアントサイドで処理を行って
すばやくレスポンスを返すことってのは重要かなと思います。
しかし実装する立場にたつと、より責務の分離が困難になってしまうのが問題。
View層の実装方針できちんと分離できているなら何も問題ないですがここが難しい。
特にRIAで従来のクラシックWebアプリケーションより出来ることが増えているので、
そもそもあるRIAではこれが出来る・これが出来ないっていうのと、
自分の案件では使う・使わないというのをきちんと見極めできる人がいないと厳しい。
まだまだこれが出来るすばらしい方は少ないように思うので、見つけたら捕獲しておきましょう（笑）
（得に複数のRIAソリューションをきちんと比較できる人って少ない。自分もそうなれる様に勉強中。）
このようにクライアントサイドのリソースを上手く使いユーザの使い勝手を向上させる点と、
開発の効率・保守性のバランスをとりつつ、最適な点を探すというのがRIAを使った開発の難しさじゃないかなあ。
（RIA開発に慣れている方々は各々こうあるべきというのを持っていると思います）
お客さんも従来のWebの操作性では満足せず、よりよいシステムとのインタラクションを
目指しています。RIAに代表される使える道具が増えて、良い操作性が実現可能な選択肢が
増えているのはお客さんもよくご存知なので、今後UIまわりはよりシビアになるはずです。
また、Javaで言えばサーバサイドの開発にはある程度の方法論・責務の分離のパターンなどが
全体の知識として蓄積がされてきているんじゃないかなあと実感していて、
それがいよいよUI層での良いインタラクションの実現に目が向いてきているのかなあと思ってます。
しかし従来型のWebフレームワークではRIAを含むWeb2.0的ソリューションとのつなぎの部分が
あまり上手くない。
例えばStrutsでViewだけFlexに！とかいきなり出来るかといえば何か作りこむ必要があるでしょう。
そこで考え出したのがT2です。
T2はこのようなRIAを含むWeb2.0ソリューション（勿論クラシックWebアプリケーションも！）との
連携部分に特化して作られています。
Web2.0っていうのもアレなんですけどｗ、RIAだけがT2じゃないので素晴らしく釣り文句ですｗ
複数のViewテクノロジと連携する・インタラクションすることがT2の最も重要な機能の一つで、
その中のひとつとして勿論RIAは必須。
おおざっぱにいえばRIAに代表されるWeb2.0ソリューション＋従来型のサーバサイド開発を
実現するためのコネクタがT2です。
釣りテーマとしては、
「Web2.0 Connector」
釣らないテーマとしては、
「The WEB Connector」
って言ってます。
「今までのJSPとかだけじゃなくって、もう少し良いUI（良いインタラクション）を
もうちょっと簡単に実現できないものかなあ？」といった悩みに応えたい、
これがT2の原点です。
まとめるとRIA時代においてプレゼンテーション層は競争の激しい主戦場になりそうです。
道具はそろってきています。が、しかし使いこなせる人材の問題、それらをつなぐ部品の問題など
ありますが、ユーザの要望と共にいろいろなノウハウが出てくるでしょう。
そんななかで、開発者の人がより適切なView層のテクノロジを選べるように、
ひいてはお客さんがより良い操作性のシステムを使えるように、
自分としても良いUI・インタラクションを生み出すお手伝いがT2などを通じて
出来ればなあと考えてます。
