「マイクロソフトのデータ アクセス技術の変移」(対談記事)

更新日: 2009 年 6 月 22 日

この記事は「マイクロソフトのデータ アクセス技術の変移」をテーマに行った対談をまとめたものになります。ADO.NET や LINQ (Language Integrated Query) などの最新技術の登場で、開発者が押さえておくべき知識やスキルはどのように変わっていくのか？マイクロソフトの提唱するデータ プラットフォーム戦略の最新トピックを押さえつつ、業務アプリケーションでの活用方法や有効な使い分けなどを議論するのが今回の目的となります。

今回はマイクロソフトからエバンジェリストである野村一行、コンサルタントとして活動している赤間信幸 (赤間本の著者と言ったほうが良いかもしれません)、そして、株式会社アークウェイから奥田直人氏をお招きしてパネル・ディスカッションを行いました。

目次

1. 正直な話
2. ADO.NET のメリット・デメリットは？
3. LINQ が持つ多様性
4. ADO.NET Entity Framework の功罪
5. ADO.NET Data Services の魅力
6. 学習ロード マップとミニマム スキルセット

1. 正直な話

【小高】 さて、まずは皆さん正直な感想として、今マイクロソフトが提供しているデータ アクセス技術をどう見ているかを教えてください。

【赤間】 正直な話、イントラネットだと ADO.NET が最も適していると思っています。LINQ も LINQ to Object と LINQ to DataSet は使いどころが多いのですが、それ以外は安易に利用すると危険だと思います。

【奥田】 私は ADO.NET Entity Framework は選択肢としてはありだと思っています。ただ、多階層のアプリケーションでの適用としては、ADO.NET のDataSet のように DTO (Data Transfer Object) としての使用は厳しいですね。これは ADO.NET Entity Framework では従来の DataSet のように変更セットだけを転送できないためで、Web サービスとして公開した場合の親和性はあまりよくないです。ただイントラネットのように擬似クライアント サーバーならばありだと思います。

【赤間】 アプリケーションの性格にもよりますよね。参照系主体であれば、LINQ to SQL や LINQ to Entity (ADO.NET Entity Framework) などを使ってもよいと思うのですが、これらの技術を使うと、少なくとも現時点では、更新処理に対しては楽観同時実行制御ベースになります。なので、悲観同時実行制御ベースの更新要件が出た場合には、別テクノロジーを併用する必要が生じます。複数のテクノロジーの併用を嫌って1本のテクノロジーだけに絞りたい、という話になると、ADO.NET のみを使っていればよいのでは? となります。さびしい話になりますけどね。

【野村】 そうですね、突き詰めると、SQL が使えれば、LINQ も ADO.NET もみんな要らないということになりかねませんね。SQL 以上にライフ タイムの長いものって今のところ考えられないですから。LINQ や ADO.NET のバージョンが変わってコードを修正しないといけなくなるのではないか、といった不確定要素をどうしても排除するなら、SQL だけが残ってしまうことになるわけで。少なくともここ 20 年はそれで行けたわけですし。

【野村】 とはいえ、マイクロソフトが追求しているユニバーサル データ アクセス構想は OR マッパーなどの仕組みなどを通じて、インピーダンス ミスマッチを乗り越える目的があるのですが、結局データベース製品の比較になってしまうのは、技術の背景や良し悪しが十分伝わっていないからだと思います。

【小高】 ぜひそれも含めた魅力をこの対談で伝えていきましょう!

【赤間】 LINQ もそうですし、Entity Framework もそうなのですが、まだまだフューチャー テクノロジー (未来のテクノロジー) だという気がしています。例えば、多層階層なシステムやスマート クライアント システムの場合、先ほど奥田さんから指摘のあった変更セットが転送できないという問題は、開発生産性上、かなりクリティカルになることがあります。

【奥田】 LINQ は開発者が必要とされるスキルを大幅に変えてしまうと思います。従来の ADO.NET や SQL に慣れた開発者が、違うタイプのコーディング スタイルが要求されるわけですから。教育コストなどを嫌って LINQ の導入を見合わせている企業もあります。そのあたりもフューチャーだと思います。

【小高】 みなさん、魅力ですよ、魅力！

ページのトップへ

2. ADO.NET のメリット・デメリットは?

【小高】 では、個別のテクノロジーについてお伺いします。ずばり ADO.NET のメリット・デメリットはどんなところにあると思いますか？

【赤間】 メリットは汎用性の高さですね。ひとつの技術で様々なシナリオに対応しやすいと思います。

【野村】 データ アクセスのパターンがプログラム内で素直に見えるところもいいですね、まずコネクションをひらいて、次にコマンドをセットするとか。

【奥田】 後はチューニングもしやすいです。SQL を直接操作するので、対応しやすい側面があります。

【赤間】 極端に高い性能を求められる場合、DataSet のインスタンス化のオーバーヘッドが大きい、といった話はよく言われますね。実際にはそれ自体はそんなにクリティカルではありませんが、ただ奥田さんの言われるように、そうした場合でも臨機応変に対応しやすいのは確かです。

【野村】 逆にデメリットは、接続型と非接続型を意識しなければならないところだと思います。

【赤間】 昔は接続数が限られていた C/S 型システムが中心だったので、サーバー カーソルを開きっぱなしにしたり、ロックをかけっぱなしにしても、そこそこ動くシステムが作れてしまったんですよね。ところが Web アプリケーションになると、そうした点を意識せざるを得ない。SQL 文やトランザクションの概念などがなんとなく分かったとしても、それが Web アプリケーションや Web サービスに組み込まれたときに、どういった形で設計・実装しなければならないのか。あるいはどのように接続型や非接続型などの考え方を使わなければならないのか。そういったことを考えるのが、思いのほかハードルが高いのが現実です。

ページのトップへ

3. LINQ が持つ多様性

【小高】 LINQ に関してはどう感じていますか？

【奥田】 LINQ は SQL を置き換えるというよりは、言語にクエリーを持ち込んだ点が、そのままデータアクセスまで通じているところが素晴らしいと思います。

【赤間】 私が個人的に好きなのが LINQ to SQL です。テーブル データをオブジェクトとみなしてコードを書くことによって、JOIN 文を書かなくて済むのが素晴らしいです。複雑なクエリーを内部で生成するクエリー ジェネレーターの部分だけでも使いたい感じです（笑）

【奥田】 Visual Studio でエディタを開いて .NET のコードを書いているときは、もちろん RDB は意識していますけど、確かにデータをオブジェクトのツリーで扱えるほうが自然ですね。

【赤間】 RDB では、基本的にテーブルというものは独立していて、処理のためのナビゲーション パスがありません。リレーションシップがナビゲーション パスだと思われている方も多いと思うのですが、実際には RDB ではリレーションシップを持たない 2 つのテーブルに対して JOIN 処理を実施できる。これは、RDB では本質的にテーブルが独立していることを意味します。けれども実際には、リレーションシップのあるところでは、リレーションシップの先にあるデータを使う必要のある処理が多くて、動的なナビゲーションが必要になることが多い。この、リレーションシップを動的なナビゲーションパスとして簡単に利用できるようになるというのが LINQ to SQL のミソだと思うのです。そういう考え方ができれば開発者にとってうれしいのは当たり前で、生の SQL を .NET 言語で扱うのと比べてはるかに生産性が高くなりますよ。

【奥田】 そうですね、後は従来の ADO.NET＋DataSet の場合、DataSet で RDB に近いテーブル形式でデータを保持しています。ただ、当然ながらテーブルの形がそのまま UI になることは少ないですから、そのために DataSet を操作する冗長な処理を大量に実装しなければいけません。LINQ (LINQ to DataSet) を利用することでそのあたりが非常に簡潔に実装できますね。

【野村】 LINQ は抽象化という視点では非常に優れています。例えばパラレル LINQ や DryadLINQ (英語) (複数の Node にまたがるデータソースの並列計算用の LINQ) などがよい例です。
これが ADO.NET だと低レベル過ぎるし、Entity Framework だと抽象化が高すぎるというか、モデルの観点が違ってきて素直に並列処理を表現できません。ちょうどよいところに LINQ があるんですね。今後クラウドに限りませんが、分散アプリケーションでの開発を行う場合などでは、物理ノードを意識しないようなプログラミングが必要になってくるはずですので、そうした抽象化を LINQ が提供してくれるのでは? という期待をしています。

【小高】 LINQ 高評価ですね、では LINQ のデメリットは？

【野村】 ラムダ式が分かりにくいって感じることがありませんか？

【奥田】 ありますね、LINQ のクエリ式やラムダ式はある意味シンタックスシュガーなわけで、正確に理解して使うためには言語実装から身につけなければならないと思います。例えば Where 句内にカスタムで実装したメソッドの呼び出しを実装しただけでもエラーになることもありますから。

【赤間】 LINQ to SQL などでパフォーマンスを要求されるとちょっとつらいですね。抽象度が上がって柔軟なコーディングができるようになっている半面、ライブラリ内部の処理ははるかに増えていますので。ここは開発生産性と性能のトレードオフですね。

【奥田】データ アクセス処理で書くコードは遥かに短くなっているのは確かですね。

【赤間】 あとは先ほどもお話しましたが、更新系で悲観同時実行制御などが出てきたときにテクノロジーが混在することになりますが、個人的にはそのような設計は避けたいところです。

【小高】 どんなシステムに向いていると思いますか？

【奥田】 やはり参照系のシステムだと思います、ただ LINQ to DataSet は既存の ADO.NET 環境の機能拡張として入れるのは、非常に優れた実装方法です。先ほどお話したように DB のモデルから View のモデル (UI) に変換しなければいけないときなどは、その強みがよくわかりますね。

ページのトップへ

4. ADO.NET Entity Framework の功罪

【奥田】 LINQ to SQL は本当によく考えられていると思います。一方で ADO.NET Entiy Framework は何かが足りないと感じています。

【小高】 急に来ましたね。では皆さん、ADO.NET Entity Framework に関してはどうですか？

【野村】 Entity Framework は、まだ発展途上という感じですよね。

【小高】 どの辺りのことですか？

【野村】 代表的なのは、概念モデルの作成が、物理データベースからスタートになるという点ですね。もちろん、直接概念モデルからの開発もできますが、手がかかりすぎます。

【赤間】 あとは概念モデルの表現力が弱いとも思います。例えば、現在の EDM (Entity Data Model) の仕様では、包含関係の表現が不完全だったり、配列データをプロパティに持つことができません。しかしこれだと、概念モデルと呼んでいるものが、機能上、オブジェクト モデルと大差なくなってしまう。しかも野村さんが言われているように、現状の概念モデルはリレーショナル モデルからのリバースで作ることが前提になってしまっている。これでは概念モデルと論理モデルの何が違うのか？が伝わりにくいんです。

【野村】 ただ、次のバージョンからは概念モデルからデータベースの作成ができますね。正常進化系のほうに舵を切っていますので期待しています。

【赤間】 RDBMS は E.F.Codd 博士がその概念を発表してから 40 年近い歴史があって、データベース製品まで含めて十分に成熟の域にある。でも、それに置き換わるような素晴らしいデータ モデリング技術がいきなり完成するわけがなくて、ある程度の期間をかけて成熟してくるものだろうと思います。そういう意味では、今後のテクノロジー トレンドとして絶対に押さえておくべきものだと思いますね。

【野村】 それと、Entity Framework はレイジーロードが実装されれば、ネットワーク トラフィックが減らせて、それこそ複数ノードにまたがるひとつのエンティティが実現できるかもしれません。

【赤間】 レイジーロードは必ずしもメリットばかりではないと思います。レイジーロードでは開発者にとって意外なタイミングでクエリーが流れてしまうことがありますが、これになじめない人も多いと思います。

【奥田】 ありますね、ただ Entity Framework は、今後の流れとして主流になってくると思います。LINQ to SQL のように SQL Server のみに対応しているというのは実際のシステム開発現場での選択肢としてありえないわけですから。後はどれくらい成熟してくるかと、ツール含めてどれくらいシンプルに使えるかですね。

【小高】 ADO.NET Entity Framework に関しては、今は足回りを固める時期かもしれませんね。

【奥田】 とは言え ADO.NET Entity Framework で今作っても、よほど複雑なシステムでなければ、問題にならないと思いますよ。コード量が今までと比べて格段に減るのは事実ですし。

また、概念モデルのみに目を向けなくても、例えば、多階層型のアプリケーションを考えたときに、ADO.NET Data Services と共に使用することで劇的に生産性があがります。もちろんパフォーマンスの面は考慮する必要はありますけど。

ページのトップへ

5. ADO.NET Data Servicesの魅力

【小高】 ADO.NET Data Services をもう少し詳しくお話いただけますか？

【奥田】 ADO.NET Data Services を使ったときに素晴らしいと思ったのは、LINQ を使用したときの多階層型のアプリケーションで、変更セットの管理ができなかったという問題が解消されていることと SOAP へのアンチテーゼがあったことです。

【赤間】 SOAP へのアンチテーゼとはどういう意味ですか？

【奥田】 スキーマという厳密な実装をしなければならない SOAP 対して、ADO.NET Data Services では、単純にデータがサービスとして公開されており、そのサービスに対して HTTP で GET や POST すればよい点です。また、SOAP でデータのサービスを作るのであれば、テーブルに対して CRUD (Create, Read, Update, Dalete) 的な実装をすることが多く、その API を毎回サービスとして実装する形になります。これは大量のサービスのインタフェースを実装・管理することになってしまい結構大変です。後、クエリーを発行することができるため非常に柔軟性があります。いずれにしても従来の Web サービス (asmx、WCF) での実装に比べて非常にインパクトがあります。
ただし、パフォーマンスが問題になりますね。そういう場合は、SOAP でチューニングしていますが、そうでない場所では驚くほど生産性が高いです。

また例えば、Windows Azure Storage を使う場合や、Silverlight でのデータ アクセスは実質 WCF と ADO.NET Data Services しか方法がありません。書いてみればすぐに分かりますが本当に圧倒的にコード量が少なく実装が可能です。

【小高】 どのようなシステムに向いていると思いますか？

【奥田】 やはり参照系ですね、更新系のパフォーマンスはあまり出ないので、特に大量データの更新を伴う処理には向いていないと思います。Silverlight との相性が非常によいので、データをグラフなどでビジュアライゼーション (可視化) するようなアプリケーションには向いていると思います。

ページのトップへ

6. 学習ロードマップとミニマム スキルセット

【小高】 皆さん色々な話がでましたが、初めて学習する場合、どこから始めていくべきでしょうか？

【赤間】 初学者が、どこから手をつけるべきか・・・そもそもステップバイステップで学習するロードマップが欠けているように思います。ちょっと書いてみましょうか。

【赤間】 まず、基本的な RDBMS に関する知識は必須ですよね。SQL とかストアドプロシージャもそうですけど。その上の階層に、ADO.NET があります。接続型と非接続型やマニュアル トランザクションといったものがここに含まれますが、ここまでの習得は絶対に必要な土台ですね。

【赤間】 その上で、アプリケーションの実装 (1 の矢印) や、テーブル アダプタや型つきデータ セットと自動トランザクション (トランザクション スコープ) を使用するタイプ (2 の矢印)、LINQ to SQL を使用するタイプ (3 の矢印)、ADO.NET Entity Framework を使用するタイプ (4 の矢印)、更に ADO.NET Data Services を使用した開発 (5 の矢印) と分かれていく。後はデータをサービスで公開する場合は WCF なども学習する必要がありますが、データ アクセスだけにフォーカスすれば大体こんな具合でしょう。

【野村】 抽象度が低い順番ですね。ただ抽象化と性能のトレードオフは常に意識してほしいです。パフォーマンスを追い求めると、抽象度が低くなって柔軟性に欠けていく、反対に抽象度が高ければ、ある程度パフォーマンスには目を瞑らなければなりませんが、代わりに開発生産性や保守性が高くなります。ただし、抽象度が高い技術は必ずしも開発者がラクをできる技術ではない、ということに注意する必要があると思います。

【赤間】 そう思います、例えば現場で時折ある議論なのですが、開発者のスキルが低いから、という理由で、トランザクションを AOP (アスペクト志向)的に隠ぺいしたい、という話をよく聞きます。確かに一見すると理にかなっているようにも思えるのですが、私は、そもそもこうした議論はおかしいのではないか？と思います。確かに開発技術が進化すればコードの抽象度は上がりますが、それは開発者がより本質的なコーディングをしなければならない、ということを意味します。

【野村】 同感です、トランザクションが実装コード上隠ぺいされていたら、開発者がトランザクションのことを知らなくてよいのかというと、そうではないはずですよね。

【奥田】 トランザクションも含めてですが、開発者には絶対に身につけてほしいミニマム スキルセットがあるのは事実ですね。

【小高】 赤間さん、このネタで本でも書いてはどうですか？

【赤間】 え゛？（笑）

いかがでしたでしょうか？この後も話は尽きず、あっという間に時間が過ぎて行きました。対談中印象的だったのは、とにかく話題が尽きないことです。これは、この分野が単にデータをアクセスするだけにとどまらず、アプリケーション設計のアーキテクチャーやパターンなど、システム開発の根幹に深くかかわり、その人個人の「思い」が如実に反映されるからだと感じました。また、一見技術が乱立しているようにも見えるのですが、その背景やトレード オフなどの概念を理解することで、多くのメリットを享受することができるのだということも分りました。記事を通じて皆様の開発に対して何かのきっかけになれば幸いだと思います。