SAOって概念どうかな

最近Ajaxプログラミングをはじめているが、

いくつか書いているうちに、だんだん個人的な枠組みができてきた。

まず、XMLは使わず、JSONを使うということではじめたが、

もういまさらJSON以外のデータフォーマットを使うということは考えづらい。

（学ぶのが面倒ともいう）

それと、いまはprototype.jsのAjax系ライブラリを使っているが、

JSONPという選択肢も近いうち出てくると思われる。

JSONP / XMLHttpRequest　の選択肢を切り替えるだけで使い分けられる

APIが欲しいなぁなんていう気がしてきている。

それと、GWTとかどうなっているのか未調査だけど、

サーバサイドのオブジェクトとJSのオブジェクトを、

なんというか、透過的に使うっていう考え方、

どういう風に組んだとしても結局そう落ち着くっていみで、

普遍的な価値のある方法論だと思える。

さて、そうなってくると、JSでDAO（DataAccessObject）みたいな

ものを作って、アプリプログラマはJSしか書かない。

みたいなアプリ開発スタイルがひとつの帰着点になるような気がする。

ここでいうJSのDAOってのは、AJAXでサーバにデータをとりにいったり、

まあとにかくCRUD操作ができて、sync/asyncの２つのモードをもってる。

そんなイメージ。（無論サーバサイドには、このJSベースDAOに

対応したCGIなりサーブレットなりが実装される必要はあるけど、

これは、DBの外部スキーマが決まれば自動的に決まるもの）

んで、さっそく、そんなもの（DAO）をつくろうかなと思ったんだけど、

今作っているショッピングカートAJAXのインターフェースには

いきなし合致しない。。

データを自由にいじれるんじゃなくて、カートに商品を追加したり、

削除したり、全クリアしたり、そいういうオペレーションをCGIで

インターフェース作ったので、それに対応するJSのインターフェース

をつくりたい。カートはDBに紐づくのではなくて、セッションに

紐づいてほしい。

そういう風に考えるとJSレイヤでサーバと通信する

オブジェクトは、DAOじゃない気がしてきて。。

つまり、やりたいことは、データにアクセスすることではなく、

サービス（ここではCGI）にアクセスすること。

そういうオブジェクト（内部でAJAX通信する）を標準化したもの

をnew するだけでつくれると、なんか楽チンじゃね？と思うので、

データアクセスオブジェクトじゃなくて、

サービスアクセスオブジェクト、略してSAOなんていうのが、

あっていいのかなと思うわけです。

GoogleをSAOだとかDAOだとかのキーワードで調べると、

CD-Rまわりの話しか出てこないので、まあ、

SAO（サービスアクセスオブジェクト）っていう言葉は

少なくとも世の中的には流通してないようで。

まあ、そんなわけで、SAOつくってみようかなと思います。はい。

ブログを書くならBlogWrite