RIAのベストプラクティスの追求

T2 RIA

見たところ同期リクエストが可能なんでね。案件に使うならこの形が実装しやすいですね。
シングルスレッドモデルもいいけど、やっぱりAdobeもマルチスレッドモデルを採用して、
業務案件に採用しやすいようなアーキテクチャが選択できる、ってのも視野に入れてほしいですね

http://d.hatena.ne.jp/shot6/20080807#c1218121210

同期リクエストは可能っぽい。使い方に関してはAMFClientだけでいえば
いろいろな使い方が出来そうで可能性を感じます。BlazeDSを上手く使えば
Appletなんかも生き返る可能性がかなりあります。AMF通信の高速さはそれだけ魅力的。
AMFClientみたいな形ならSwingなんかからも使いやすいでしょう。


で、業務案件に採用しやすいようなアーキテクチャとかを考えるなら、
RIA全体でどんなアーキテクチャが勝ちパターンなのかっていうのを
つきつめて考えるのがベターだと思う。

FlexをはじめとするRIAが普及期に入ってきているので、そろそろそういうところで
確固たるやり方が出てきてもいいのかなと。


自分の今のお奨めは、
　+ユースケースごとにサーバサイドへのリクエストを投げるクラス（Requester）
　+RIA側でMVC
　+サーバサイドでもユースケースごとにリクエストを受け取るサービスクラス

の構成かな。1はユースケースごとにFlexのRemoteObjectを使ったAMF通信や
HttpServiceをラップしてしまうクラス。仮にRequesterとか名づけておく。
Flex/AIRであれば王道はAMF、Silverlightであれば、RESTかJSONでのデータのやり取りかな。
面倒くさいリモーティングまわりを全部押し込んでしまう感じ。コールバックもここらで
一手に引き受ける。
また、例えばAIRの場合はここでサーバサイドの死活監視をして、サービスが動いて無さそうなら
ローカルにいろいろリクエストを溜め込んだりもできる。その場合、その後に
サービスが復旧した際にバッチ的にリクエストを投げてもよいようにサーバサイドを
設計しておかなくてはいけないので、ここは難易度高めになるかもしれません。


で、MVCのところは、FlexであればViewはmxml。Viewには振る舞いを記述しない。
Controllerがその挙動を一手に引き受けるようにしておき、Viewに記述しておく。
またそのViewで使用するデータはModelとして定義しておき、
Requesterとの間で相互にやり取りするデータもModelにしてしまう。


次の3のサーバサイドもポイント。
SOA的な話でここはサーバサイドの受け手をいきなりサービスクラスとしたいところだけど、
そこはRIAのリクエストをきちんと処理するレイヤを設けておき、
実際のServiceクラス（トランザクションの開始地点）と明確に分離しておくほうが
望ましいと思います。実際に送られてきたリクエストの検証もあるのでね。
というわけでT2を使った場合だとサーバサイドはPageがRIAリクエストの受け手として動作し、
問題無さそうであればServiceを実行という形になります。
通常のWebアプリケーション、例えばStrutsを使った場合でも、Action+Service+Daoのような構成に
なる事が多いので、かなり似た感じになるはず。
ここら辺は通常のWebアプリケーションと同じように違和感なくRIAのリクエストを受け取れるように
T2では気を使ってはいます。



RIAのベストプラクティスみたいなもの、大きな案件でもある程度堅牢に使えて
ブレが少ないパターンみたいなものは今後も追及していきたいところです。
他の人の意見も聞きたいので、コメント等で反応もらえると嬉しいです＾＾