リッチインターネットアプリケーション（RIA）の開発では、ある技術がデータバインディングをサポートしているかどうかとそのやりやすさが、一つのポイントになる、と感じている。
俺がデータバインディングという概念を初めて意識するようになったのは、Flex 3 が最初。その後、Silverlight や WPF ではどうなのかをわんくま勉強会で聞いたり、Seasar Conference では Uruma や S2Swing でもちょこっとデータバインディングについて話していたのを聞いた。それらを聞いて今感じていることがある。データバインディング機能の優劣だけでは、ある RIA テクノロジーがこの先生きのこるかどうかを決定付けるほどの重要さは無い。ただし、データバインディングがやりやすいかどうかはリッチなアプリの開発がやりやすいかどうかにジワジワと利いてくる。このため、データバインディングは「地味だが意外と無視できない」代物と言えるのではないか、と俺は思う。
本エントリでは、今のところ俺がデータバインディングについて理解していることなどを書く。
忙しい人のための「データバインディングはなぜ重要なのか」
データバインディングとは「ユーザインタフェースとアプリケーションのロジックをカンタンに分離」するための技術。この「分離」する部分の設計＆実装は、各アプリケーションごとに似通った構造になるが、自力で設計＆実装するのは意外と厄介な代物でもある。このため、言語や環境がデータバインディング機能を提供してくれていると、この「分離」部分をイチから作りこむ必要がなくなるというメリットがある。
……とまぁ。ベンダー広告のようなビミョウに疑わしげな言い回しの概要はこの辺にしときましょう。
データバインディングとは
Wikipedia にわかりやすいまとめ文があったので、それを全文引用。
データバインディング（データバインド、あるいはData Bindingの訳からデータ結合とも呼ばれる。）とは、XMLなどのデータソースとアプリケーションやウェブページ（ウェブアプリケーション）のユーザインタフェースを静的または動的に結合する技術である。分離されたデータソースとユーザインタフェースの間を橋渡しする役割を果たし、データが変更されるとそれに応じてユーザインタフェースが変更される一方向なデータバインディングと、併せてユーザインタフェースの変更または操作に応じてデータが変更される双方向のデータバインディングがある。
データバインディング - Wikipedia より抜粋 ※太字強調は俺によるもの
ここで述べているように、データバインディングは結構広い概念である。俺は Flex で初めてデータバインディングという概念を知ったので勘違いしていたが、RIA に固有の概念というわけではない。
実際、Java や ASP.NET で Web アプリを書いたことがあるのなら、データバインディングはかなり身近な概念である。Wikipedia のデータバインディングのぺージでは、実装例に Apache Struts と、多数の Java 屋さんにとって身近なものを挙げているが、これは ActionForm 周りのことを指していると思われる。そういった意味では、Teeda や Wicket もデータバインディングしていると言えるだろう。ASP.NET も挙げているが、コレは恐らくコードビハインドモデルのことだろう。ちなみに Silverlight は、どうやら ASP.NET の流れを汲んでいるようなので、ASP.NET 開発で得られた知見は― XAML を理解する必要があるとはいえ―それなりに流用できるのではないか、と思う。
データバインディングは何が嬉しいのか
俺が思うに、Wikipedia からの抜粋部分で太字強調した部分が、データバインディングの最大のメリットである。小規模なアプリケーションであれば、ユーザインタフェースを記述するコードとアプリケーションを記述するコードを一つのファイルにまとめてしまっても問題は無いが、そこそこの規模になると、これらを分離する必要が出てくる。その理由についてはメンドウなので割愛する。
そして、この分離部分を自力で設計＆実装するのは結構な労力がかかる。無論、これは古くからある設計課題なので、パターンとして整理されている。アーキテクチャという大きな視点では MVC、もうちょっと落とし込んだ設計上の知見としては Observer パターンがある。
しかし、これらの知見を個々のアプリケーション開発で実装に落とし込むのは意外と面倒くさい。そのうえ、本来そのアプリケーションで本当にやりたいこと―いわゆるビジネスロジック―とは本質的には関係が無いコードでもある。少なくとも俺は Swing の開発では、『分離』をどう設計＆実装するかはかなり悩んだことがある*1。
また、デザインパターンとして定義されるくらいなので、アプリケーションそれぞれでそんなに違いが出る部分ではない。このため、フレームワークやライブラリが存在しない―もしくは、その存在を知らずに開発を始めた―環境で 2 回目の開発に入ると「誰か前のアプリで作りこんだ『分離』部分をフレームワークとして提供してくれ！」という状態になる*2。
とまぁ、そんな「やってらんないね、マッタク」をナントカしてくれるのがデータバインディングの嬉しいところである。
なんでデータバインディングに注目なのか
このように、データバインディングは「データバインディング」という名称が出ているかどうかは別にして、古くからある話題である。にもかかわらず、なぜ俺が注目するかというと、Web ベースの業務アプリが再びクライアント側重視の流れになりつつあるように感じているため。
RIA という概念やそれを実装した製品は、俺が覚えている限りは 10 年は前からある*3。RIA がここ最近注目され始めたのには、色々な要因が考えられると思うが、その辺りについての歴史的経緯を考えるのは今回はパス。
とりあえず重要なのは、Web ベースの業務アプリの流行の一つに、再びクライアント側重視の流れがあるらしいこと。Web アプリは、サーバサイドで色々ゴチャゴチャ処理したあと最後にヴァーンと html を吐き出して終わり、というシンプルなのが基本形である。しかし、Ajax, Flex, Silverlight などなど―どんな技術を採用するのかの違いはあるが―こうしたリッチな技術を使う場合、データ表現は html、サーバ側で何がしか処理、とシンプルな分離だけでは収まらなくなる。
こうなると、Web ベースといえどもユーザインタフェースに近い部分のアプリケーションの設計は、一世代前の流行であった C/S のそれに近い性質を帯びるようになる。つまり、C/S 時代に直面していた設計課題と再び向き合うことになる。そして、その設計課題の一つにデータバインディングがある。
データバインディングを自力で作りこむメンドウさは先に述べたが、その上 Web とも親和性の高いモノを自力で作るのは、業務アプリ屋さんレベルではもはや現実的ではないだろう。このため、俺は、ある RIA テクノロジがデータバインディングを有しているか・使いやすいかどうか、は一つのキーポイントになるのでは、と考えている。
この先 Web アプリのアーキテクチャはどうなっていくのだろうか的な何か
データバインディングからは脱線して。このエントリでデータバインディングについて書いていて思い浮かんだモヤモヤをテキトーに垂れ流し。
「Web ベースの業務アプリの流行の一つに、再びクライアント側重視の流れがあるらしい」と書いたけど、ROA やらのサーバ側重視の流れがマッタク無くなったわけではないことにも注意する必要があると思う。業務アプリのアーキテクチャの潮流は、サーバ側重視とクライアント側重視を行ったりきたりしてきた歴史的経緯がある。しかし、俺は、ここ数年でそのギッコンバッタンの速度がすごい加速し、その境界も透過性が上がってきたおかげで曖昧になっているように感じる。こうなると、業務アプリの流行がこれからどうなるかが予想しにくい。
具体的には、RESTful の思想が業務アプリに対してどんなインパクトを与えるのかが今ひとつよくわからない。RESTful Webサービス で論じられている ROA の思想はとても美しいとは思うが、ちょっと理想論すぎるんじゃないのか、と（今のところは、だが）感じているため。ちょっと大げさすぎるんじゃないの、と思っちゃうんだよね。でなければ、RESTful Webサービス で言うところの、RPC スタイルないし REST-RPC ハイブリッドなアーキテクチャが流行っちゃうようなことは無かっただろうし。
ただし「これから」はどーなるかわからんなーというのが正直な感想。Web 全体としては、ROA な方向になっていくだろうとは思うけど、その結果が業務アプリのアーキテクチャにどんな風に影響与えるのかが今ひとつ分からないんだよなぁ。
そういえば、Tech・Ed 2008 のとあるセッション では、SOAP 的なやり方はイントラなんかの閉じた世界でだけ使われるようになっていくだろう、って言ってたっけか。うーん……そういう風になっていくのかなぁ。
