Entry

プログラミング・メモ - データモデルとしての XML

2007年08月21日

ちょっと前にクラス図の他にデータの持たせ方をどうしようか,みたいな話を書いたけれども,ここら辺の話で,XML を内部的なデータモデルとして使うことをボチボチ検討しています。

「内部的なデータモデルとして使う」というのは,つまるところ View として出力しないデータについても,XML のまま扱おうということ。MVC で言うなら,Model から View に値を受け渡すところや,ビジネスロジックがある場所なんかで,XML のドキュメントモデルをそのまま持たせてみたら,どうなるだろう,とボチボチ思っているわけです。

どうしてこんなことを考えているのかというと,主に3つの理由があります。

  • XML をパースしてさらに内部的なデータモデルに変換する場合,かなりのオーバーヘッドがかかりそう。また,XML 以外のデータモデルを採用したとしても,出力先が HTML の場合は,相応のオーバーヘッドがかかる。
  • DOM に標準的なメソッドがあらかじめ組み込まれているため,車輪を再発明する必要がない。
  • ウェブベースのアプリケーションを扱う際に,XML だと (X)HTML と親和性が高いことから使いやすい。

View と Model の受け渡しで言うと,一般的には DTO(Data Transfer Object)みたいなもんを作ることになります。一方,XML を使う場合は,内部的に DOM を生成して View に渡すことになります。で,後者の優れた点は,View として見ると出力対象の元ネタ(データ)として見えるけれども,Model 側から見るとオブジェクトモデル(DOM)として見える,という点。View と Model の受け渡しには,こうした両義的な役割を持っているデータモデルを使うのがやりやすいと思っていて,DOM はこれにピッタリというわけ。

というわけで,内部的にも XML のまま扱う方が都合がいいんじゃないか,とつらつら……。この点で,IBM developerWorks に,こんな話がありました。

XML の強み

XML が良質である点の 1 つは、比較的単純であることです。XML は基本的なテキスト・エディターやワード・プロセッサーを使って作成でき、特別なツールやソフトウェアを必要としません。XML の基本的な構文はネストした要素で構成され、一部の要素は属性と内容を持っています。要素は通常、開始タグと終了タグという 2 つのタグで構成され、それぞれのタグは開始の < tag > と終了の < /tag > のように大括弧で囲まれます。XML は大文字小文字を区別し、空白を無視しません。XML は多くの人におなじみの HTML と非常に似ていますが、HTML とは異なり、タグには最も適切にデータを表す名前を付けることができます。それ以外に XML の利点としては、自己記述型で人間にも機械にも読み取れるフォーマットであること、Unicode をサポートしているため人間の言葉に関する部分の国際化が可能なこと、構文や構文解析に対する要求が厳しいことなどがあげられます。残念ながら、PHP5 では UTF-8 は問題を起こしがちです。この欠点が、PHP6 を開発する推進力の 1 つとなっています。

XML の弱み

XML は大量のテキストを含んで冗長であり、その結果として保存するための容量も大きく、そして膨大な帯域幅を消費します。人間も XML を読めるはずですが、7 百万ものノードを持つ XML ファイルを人間が読めるとは思えません。最も基本的なパーサー機能は、あまり広範なデータ型をサポートしていません。そのため XML によく含まれている不規則なデータや例外的なデータは、構文解析が困難となる主な原因となっています。

IBM PHP 開発者のための XML、第 1 回: PHP での XML… - Japan

XML を内部的なデータモデルとして考える場合,人間に読めるかどうかや,パース時のオーバーヘッドはあまり問題にしなくてもよさそうです(内部的に DOM オブジェクトを作るから)。

ただ,ここで問題になるのは,「XML の弱み」にある「広範なデータ型をサポートしてい」ないことなんじゃないかと思います。Java 界隈では Relaxer をはじめとして,XML を Java オブジェクトにマップする機構が整っているけれども,他の言語には無いか,あっても活用されていない感じがします。また,こうしたマッパは,ソースコードやクラスの相互関係をきれいに保つことができるものの,データモデルを抽象化している分だけ,性能的にいまひとつになりそうな感じもします(憶測ですが)。

この前のエントリでは,View 側にロジックが入り込んじゃう話と,ロジックに View 的な要素がこびり付いてしまうことが問題だったのでした。としてみると,XML がサポートしきれていないデータ型については,素直に XML を使わないのも,ひとつの手なのかもしれません。View との受け渡しに使うことに限定すると,こんな感じのクラス図になるのかな。

XML を使った View の図

ViewModel という View 専用のデータモデルを用意して,View に渡すスタイルシートや XML を作ったり,本来の Model 部分と橋渡しをしたりさせる……みたいな。View の部分は XSLT で変換することを想定していて,static でもいいなじゃね?ってなくらい,簡素なもんにしておきます。渡されたもんの中身を見ずに,黙って変換だけする感じ。

XSLT Stylesheet を想定しているのは,言語依存のテンプレート(Smarty とか)と違って,使用言語に対して中立的だからです。PHP を使っていたけれど,後になって Java に変えたくなったとかいうときも,(フォーマットに限っては)手を付けなくてもよくなります。もっとも,この方法を採っても,Stylesheet にロジックが入り込んでしまうと,元も子もないので,注意する必要があるのかも。ここでは,ViewModel にできるだけ大きな裁量を与えて,ここにロジックを収めてしまうことを考えているのだけれど,これも文書の可読性が損なわれないこととのバランスの話だったりして。

どうも,考えながら書いていたので,まとまりがつかなくなっちゃいました。きれいに作ろうとすると,オーバーヘッドが気になるし,泥臭く作ると可読性が損われる……いい落とし所はないもんですかね。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN