|
|
第1回 LINQの特徴とメリットを知る
2007年12月,Visual Studio 2008日本語版(以下,VS 2008)がリリースされた。開発者の注目の的は,「LINQ」(Language-Integrated Query,統合言語クエリー)である。LINQと,任意の開発言語(Visual BasicやC#)を使いこなせば,データ処理が劇的に変わるのは明らかだ。 本連載では,「LINQ to XML」の基本を5回にわたって紹介する。これは,Microsoft .NET Framework 3.5上で利用可能な,XMLデータ処理のためのクエリー言語である。XMLデータの抽出/検索,XMLツリーの生成/変更/削除/更新,シリアライズといった処理を実装するために使うことができる。 「LINQ to XML」についての解説は,Visual Studio 2008のヘルプに詳しい。マイクロソフトのサイトでは,多数のサンプル(Visual BasicまたはC#)も提供されている。しかし,RDBの専門家は,最初の一歩をちゅうちょするかもしれない。また,XML技術者は,W3CのXML関連仕様とLINQの違いにとまどうかもしれない。 そこで,本稿では,「LINQ to XML」の技術仕様の側からではなく,XMLデータ処理の側から「LINQ to XML」を見ていく。具体的には,ASP.NET XML Webアプリケーションで現在不可欠なXMLデータ処理のコードを,「LINQ to XML」を使って置き換えるにはどうすればよいかを,具体的にサンプル・コードで示す。 ぜひ,実際にコードを入力して,LINQのメリットと可能性を体験していただきたい。
LINQの意義と特徴LINQの登場で,開発者の仕事は大きく変わる可能性が高い。学習が容易になり,実装がわかりやすくなり,設計の汎用性が高まる。実際のコードについて見る前に,これら三つのメリットについて説明しておこう。 (1)高汎用性 〜学習が変わる〜通常,XML仕様に則ったXMLデータを処理するには,W3Cで策定された次の仕様を習得する必要がある。
このうちDOM,XPathは開発者にとって必須であり,XSLTも必要度が高い。XQueryは,XMLデータベースを使う場合に必要になる。ただし,DOMには,ベンダーの独自仕様があり,XQueryにいたっては,採用したXMLデータベースで,必ずしもW3C仕様がサポートされているとは限らない。よって,W3Cとベンダー双方の仕様を学ぶ必要がある。さらに,処理に適した仕様を選んで組み合わせるには,これら四つの仕様をすべて習得する必要がある。 Visual BasicやC#には長けているが,XML関連仕様の学習はこれから――そんな開発者にとって,LINQは福音である。これら四つの仕様を使う処理の多くが,LINQで代替できるからだ。LINQを使ったXMLデータ処理に慣れてから,他の仕様に取り組めばよいだろう。 Microsoft SQL Serverに長けている開発者であれば,LINQの構文はSQL文に似ているので取り組みやすい。LINQクエリーの基本コーディング・パターンは,XML文書であれ,SQL Serverデータベースであれ,処理対象のデータ形式が異なったとしても共通なので,データ形式別に異なるクエリー言語を習得する必要がない。 また,従来のSQL文などとは異なり,LINQクエリーのコーディング時に,Visual Studio上でツールチップ・ヒントやインテリセンス機能が利用できるので,入力の手間が大幅に軽減される(図1)。
もちろん,W3C仕様に慣れているXML技術者にとっても,LINQの構文はXQueryに通じるものがあるので理解しやすい。LINQ to XMLを習得することで,SQL Serverデータベースの処理にも取り組みやすくなる。 このように,LINQは,XMLデータ処理のための学習を容易にしてくれる。ただし,LINQを習得したからといって,処理対象とするXMLそのものについての学習まで免れる,というわけではない。XMLそのものを理解するために,次の三つの基礎知識は必要になる。
この三つのうち,XML Schemaについては,スキーマでの検証を行わないのであれば,学習は後回しにしてもかまわない。XMLの設計書は,Excelでツリー構造を書くといった,XML Schema以外の方法で記録したのでもかまわない。 (2)高機能 〜実装が変わる〜LINQ to XMLは,実にハイパフォーマンスな仕様である。データ取得やフィルタリングに加え,投影,ソート,グループ化,結合などの強力な機能がある。.NET FrameworkでSystem.Xml.Linq名前空間に含まれるLINQ to XMLのクラスが提供する機能を使えば,XML案件で頻度の高い処理の大部分を実装できる(表1)。従来複数の仕様で実装していた処理を,LINQ一つで代替できるのである。 表1●LINQで代替できるXMLデータ処理の実務でニーズの高い処理
※System.Xml.Linq名前空間については,VS2008のヘルプに詳しい 例えば,通常,SQL ServerをXMLデータベースとして利用するには,XML型の列にXMLツリーをそのまま格納し,SQL文の中でXQueryのPath式を使う。これでは,RDBあってのXMLである。しかし,LINQを使えば,XMLとRDBを対等な関係で扱うことができる。XMLデータ側の任意の要素とSQL Serverデータの主キーを統一しておけば,シンプルなコードで連携処理を実現することも可能だ。ミドルウエア(XMLデータベース)の採用基準が変わり,実装に影響が及んだとしても,少ない修正で済むだろう。 (3)ポストXML 〜設計が変わる〜学習が容易で,機能が豊富――実装者には,取り組んであり余るメリットがある。一方,XML技術者は,設計思想そのものの再構築を迫られることになる。本連載の目的はLINQクエリーにあってXML設計にはないので詳しくは別の機会に譲るが,ごく簡単に説明しておこう。 XML設計は,データ作成,XML仕様,プログラムのうち,どれにプライオリティを置くかによって異なる。開発の現場では,データの意味を的確に表すタグを付けるとプログラムが複雑化したり,逆に処理効率を優先すると最大階層やタグ名に制限を設けなければならないといったことがある。次の三つは,往々にして相容れないのである。
例えば,絞り込み検索と付随情報の抽出とでは,プログラムで処理しやすいXMLの構造は異なる。そのような場合,DOMを使って,処理目的に応じた複数の構造のXMLツリーをメモリー上に展開してから再処理する,といった方法を採用することがある。ところが,LINQを使えば,1種類の構造で複数の処理目的に対応できる可能性がある。XMLのメリットである,ワンソース・マルチユースの効果を発揮しやすくなるわけだ。 また,SQL Serverデータや(VS 2005以降で自動接続可能な)属性主体の複数のXML文書のリレーションシップを,XML形式の設定ファイルで定義しておき,LINQによってリレーションを制御し,処理することもできるだろう(図2)。筆者は,純粋なXMLの後には「リレーショナルXML」とでもいうべき,RDBとXMLのメリットを併せ持つハイブリッド仕様が登場すると見ている。LINQを,現行のXML仕様と,ポストXML仕様の過渡期をつなぐための機能としてとらえている。
前置きはこのくらいにして,次ページから,いよいよLINQ to XMLのコードを見ていこう。
>>W3C仕様とLINQ構文の違い
連載新着連載目次へ >>
|