移行すべき適切な時期

Dino Esposito
Microsoft Corporation

February 8, 2001
日本語版最終更新日 2001年4月13日

この記事は、もともと MSDN Online Voices のコラム "Diving Into Data Access" に掲載されたものです。

"Diving Into Data Access" へようこそ。ここは、データアクセスの問題点とその解決策の調査を専門に行う新しい Voices コラムです。

私は Dino Esposito と申します。私の名刺の肩書きではイタリアのローマに本社がある会社のトレーナ兼コンサルタントということになっています。以前は、かなり初期の Windows DNA の実装作業の一部を分担しており、インターネット時代以前のヨーロッパの最初のオンラインイメージデータバンクの開発で重要な役割を果たしてきました。

現在は、主に MSDN Magazine で "Cutting Edge" コラムの記事を書いています。それ以外の時間は Wintellect の ADO.NET クラスと ASP.NET クラスで教鞭をとっているか、企業の .NET プラットフォーム移行計画のお手伝いをしています。

分散システムでは、データ層は人々があまり関心を持たないものの 1 つです。実際、設計時と実装時の両方で、スケーラビリティ、パフォーマンス、および相互運用性といった一見大きな問題に注目しがちです。

開発者は、きっと意識下で頻繁にこんなメッセージを受け取っているのではないでしょうか。「優れた DBA を雇っているのだから、データベースに時間を浪費するな。コンポーネントに努力を集中しろ」と。しかし、パフォーマンス、スケーラビリティ、および相互運用性を向上する手段を具体化していくと、データアクセス層は私たちが見ていく必要のある最初の要素であることがわかります。

そこで月に 2 度、私はこの入り組んだ森を徹底的に調べていくつもりです。始めるにあたって、｢ADO.NET の出現が皆さんの生活をどのように変えていくのか｣という私の主題に触れておきましょう。

長所と短所

ADO.NET にも、長所と短所があります。私は、このコラムでこれらの問題を調査および研究していくつもりです。ところで、この長所と短所に関する私の考え方を説明する逸話をご紹介しておきましょう。

ある IT マネージャが亡くなり、天国のドアをノックしました。一旦中に入る (ログオンする) と、彼は天国に行くか地獄に行くかという厳しい選択を迫られてしまいました。最終的な決断を下す前に、天国で 1 日、地獄で 1 日過ごせるよう交渉し、それを何とかその交渉を成立させることができました。

地獄で過ごしている間、彼は亡くなったたくさんの同僚や友達に会います。彼らとゴルフをしたり、立派なレストランで食事をしたり、次から次へとパーティを渡り歩く夜を過ごしました。悪魔の容姿は、気楽なナイスガイのように見えます。｢悪くないな｣と IT マネージャは思いました。

天国で過ごしている間、彼は天上の音楽を楽しみ、天使と一緒に飛び回り、雲から雲へと飛び移り、くつろいだ時間を過ごしました。｢これが永遠に続くのは退屈すぎる｣と彼は思います。

全体的に見て、彼は地獄で過ごした時間のほうがかなり楽しかったと考えました。そこで、彼は地獄に行きたいと望み、エレベータで降りていきます。しかし、ドアを開けると、彼はそこで現実の地獄を見ることになります。悪魔は、彼を元気付ける様子ではなく、彼が期待していたように振舞いません。

｢なぜこのように突然変わったのですか?｣とその IT マネージャが尋ねると、悪魔はこう答えます。｢昨日、私たちはあなたを雇っていました。今日、あなたはチームの一員です。｣

この話から学べる ADO.NET の教訓はあるのでしょうか ?

ADO.NET は、天国でも地獄でもありません。間違ったプロジェクトに着手するか、間違った方法でプロジェクトにアプローチすると、今日天国のように見えたものがすぐに悪夢となり得ます。もちろん逆の場合もあります。

あなたが IT マネージャ、開発責任者、または過小評価されがちなデータアクセス担当の単なる一員であっても、決して見かけにだまされてはいけません。ADO.NET によって表面化する利点や問題点といった、プロジェクト固有の考え方を左右する点を 1 日以上の時間をかけて検討してください。

ほかの多くの新しいテクノロジのように、ADO.NET は世界を変える方法、ときには世界を救う方法とさえ表現されることがあります。過去において、私たちは ODBC を革命として、RDO を大きな前進として、そして ADO をデータアクセスを強化する一方で、簡略化を進める過程の最終段階として認識していました。この点では、ADO.NET は事態の自然な流れとして、アップグレードする何番目かのデータアクセス層として合理的に出現したように思えるかもしれません。

ADO.NET への移行は、簡単なステップではありません。ADO.NET は .NET Framework に不可欠で、一貫性がある一部です。データアクセスに必要であるからという理由で ADO.NET を選択してはいけません。そうではなく、.NET をプラットフォームとして選択した結果として、データ処理のコード用に ADO.NET を使用します。

移行に適切な時期を待つ

季節の変わり目は、常に移動に適切な時期です。これは鳥にも情報システムにも当てはまります。鳥はより暖かい地方に向う時期を自分で判断できる内臓のメカニズムを持っています。しかし、残念ながら情報システムや Web アプリケーションにはこのようなメカニズムはありません。

私は、移行に適切な時期が必ず存在するとは考えていません。また、そういう時期があるとしても、それを決めるアルゴリズムは存在しないでしょう。今日実行しているコードが十分に高速で、少なくともクライアントの期待の大部分を満たしている場合は、コードを移植することを急がないでください。

その一方で、.NET の準備を始めることができます。アップグレードに関する決定を行うときは、得られるものと失うものを検討してください。.NET では、アップグレードにかかる時間を慎重に考慮する時間を持つことも必要です。データアクセスは、情報システムのほんの 1 面にすぎません。しかし、それは世界規模のすべてのアプリケーションが共通に持っている側面でもあります。

できる限りすぐに移行することが適切である理由もあれば、移行を待つことにも同様に適切な理由があります。どちらの場合でも重要なことは、一般的な .NET について、さらに特にデータアクセスについてできる限り多くのことを学習することです。

データアクセスは、実社会のすべてのアプリケーションにとって重要なものです。しかし、.NET のデータアクセスは、旧バージョンと完全に互換性があるわけではありません。たとえば、既存の Active Server Page を対応する ASP.NET ページに変換することは比較的簡単です。それが機能するように適合させるプロセスで必要な変更はわずかです。 (さらに、サーバー側の JScript を使用している場合は、重要なパフォーマンスの向上を調べる機会もあります。これは JScript .NET option(fast) スイッチを使用して実現できます。) ただし、既存の ADO コードがそのまま ADO.NET コードになることはほとんどありません。それは、.NET アプリケーションのコンテキストで機能する ADO コードになるだけです。

現実のアプリケーションは、COM コンポーネントを使用します。このようなアプリケーションは、データプロバイダに対して動作し、ASP の出力ストリームに直接書き込みます。あるいは、レコードセットや XML 文字列を使用してデータを返します。このようなコードは、あまり苦労せずに .NET への移行を達成できます。これは、コンポーネントのタイプライブラリをインポートするには十分で、.NET が提供する COM Interop ブリッジのおかげで引き続き機能するでしょう。

このように移行することは本当に意味のあることでしょうか ? 最大限に.NET を利用するためには、その内部アーキテクチャを理解し、新しい考え方を受け入れる必要があります。実際には、.NET の考え方は、有名な COM の考え方とあまり変わりません。ただし、異なるオブジェクトを管理し、以下のような異なる規則に従って考える必要があります。

では、一般的な .NET と特殊な ADO.NET の間でどのような立場をとればよいのでしょうか ? 私は、これには次のような 3 ステップのガイドがあると考えています。

ADO オブジェクトについては忘れます。
ADO.NET の原理とオブジェクトを使用するコードを見直し、書き直します。
以前の ADO の経験に照らしてコードを洗練し、最適化します。

つまり、ADO や OLE DB コーディングの詳細を忘れます。ただし長い時間をかけて学んだ背景となる概念は維持し、再評価するということです。ADO.NET を考慮しながら、それらをもう一度検討してください。ADO.NET が本質的に洗練されていて、首尾一貫したもので、ADO よりかなり用途の広いものであることに気づくでしょう。それは、OLE DB と同様の柔軟性がありますが、C++ のように熟練し、かなり洗練された開発者に限定されることはありません。ADO.NET が OLE DB よりかなり単純であると同時に、OLE DB よりもさらに特化されていることに気づくでしょう。

ADO.NET を理解するために、少し時間をかけてください。ADO.NET と ADO を比較し、独自の特定のコンテキストで物事をどのように変更し、改善できるかを考えてください。詳しくは、Comparison Between ADO and ADO.NET をご覧ください。

移行する理由

ADO.NET および ASP.NET に移行する説得力のある理由は、そのパフォーマンス、および開発と保守が容易な点にあります。ASP.NET と ADO.NET の双方には、いくつか共通する最適な原則があり、すべてが含まれた、一貫性のあるフレームワークにそれらを統合します。

Web アプリケーションを書き直す場合、まさに探している処理を行うコンポーネントが存在することにすぐに気づきます。サービスとして動作し、Internet Information Services がクラッシュしても動作し続けるセッションマネージャがあります。複数のテーブルレコードを埋め込むオブジェクトがあります。予期せぬ障害に見舞われることなく ASP.NET セッションオブジェクトにオブジェクトを格納できます。独自のストアドプロシージャを使って、任意のデータプロバイダに対してバッチ更新を行うことができます。高度なカスタマイズが可能な DataGrid コンポーネントをすぐに使用できます。任意のレコードセットを XML に変換するためのオーバーヘッドがありません。XML スキーマを自由に変更できます。レコード全体を最適に処理するナビゲーションモデルを選択できます。

プレゼンテーション層、中間層、またはデータアクセス層のどの範囲を考えても、.NET の開発は容易です。さらに、対象とするプログラミングモデルが Windows フォーム、Web フォーム、Web サービスのどれであっても、ADO.NET は同じもののままであるオブジェクトのセットを提供します。バックエンドにデータソースがある限り、ADO.NET は同じ種類のヘルプを提供します。

また、ADO.NET に移行することにより、ADO と OLE DB のコンポーネントを二元管理する必要がなくなります。今日では直接 OLE DB を呼び出すことは C++ のみで可能です。それらは高速ですが、エラーを引き起こしやすい傾向があり、すべてのチームで利用できない特殊なスキルが必要です。それに対して ADO は、ASP および Visual Basic の開発者向けに特別に設計されており、C++ プログラマも歓迎するような豊富な機能を提供しています。

ADO.NET は、ホストしているフレームワークとは中立の言語を利用することによって、この二元管理の必要性をなくしています。言語やプログラミングモデルとは無関係に、同じ機能の組み合わせを提供します。

待つ理由

この記事の前半で説明したように、ADO.NET への移行は単一のステップのプロセスではありません。その場しのぎの手段はありません。システムを元の状態のまま残すか、最初からシステムを考え直して、中長期の移行計画を明確にします。

ADO.NET の新機能や新しいオブジェクトを利用するために、その中核となるデータアクセス機能を再設計する必要があります。

.NET を学習しながら、現バージョンのシステムを管理するようなリソースをお持ちですか ? 中核となるシステムに手をつける前に、最低 1 つテスト的なプロジェクトを経験する必要があります。.NET への挑戦を軽く見ると、当初の予算を大幅超えてしまう危険性があります。

ADO.NET プロジェクトでは、ユーザーのデータベース、SQL、および ADO に関するスキルを 1 つの尺度とします。それに、ADO.NET に組み込まれた新しいオブジェクトモデルや新しいポリシーを調和させるように努めます。その後、問題点やデータアクセス戦略に対する理解度を基盤として、ユーザー独自のコンテキストに組み入れることができます。ADO や OLE DB に対する高度な知識を使用できます。さらに Web を使って作業している場合は、IIS や ASP の経験にも依存することになります。

移行の 3 段階

既存のシステムを .NET に移行するには、まず少なくとも 1 つのサーバーに .NET ランタイムをインストールします。インストール後に、元の中間層オブジェクトの変更を開始できます。それぞれが .NET の特徴を表す個別のサーバーで実行する新しいページやコンポーネントを変更したオブジェクトから呼び出させることができます。

図 1. Web サービスインターフェイスを使った、既存のシステムと新しい .NET システムとの通信

図 1. Web サービスインターフェイスを使った、既存のシステムと新しい .NET システムとの通信

ユーザーは、引き続き ASP ページを呼び出します。ASP ページも引き続き順次同じ中間層オブジェクトを呼び出します。ただし、これらの中間層オブジェクトは、バックエンドの .NET が有効なシステムとの間に新しいチャネルを開けるようになりました。では、COM(+) と .NET オブジェクトはどのように通信するのでしょうか ? この通信には Web サービスインターフェイスを使用します。Web サービスを呼び出すには、そのプログラミングインターフェイス (Web サービス記述言語 (WSDL) と呼ばれているもの) だけを理解する必要があり、文字列を返す XML を処理する準備が整います。次のスクリプトコードは MSXML 3.0 を利用して、ASP ページまたは COM オブジェクトから Web サービス上のメソッドを呼び出しています。

Set srvXmlHttp = CreateObject("MSXML2.ServerXMLHTTP")
Set xmlResult = CreateObject("MSXML2.DomDocument")
srvXmlHttp.Open "GET", 
"http://myserver/myapp/webservice.asmx/Method", 
false
srvXmlHttp.Send ""
Set xmlResult = srvXmlHttp.responseXML

xmlResult オブジェクトは、サービスが返したデータを持つ XMLDOM 文書を保持します。

もう 1 つのアプローチは、いわゆる COM Callable Wrapper (CCW) エンジンを呼び出します。このエンジンは、コモンランゲージランタイム (CLR) で実行され、.NET クラスインターフェイスを COM 準拠のインターフェイスに変換します。つまり、CCW が .NET クラスを COM オブジェクトに変換し、その結果任意の既存の COM クライアントがそれを呼び出せるようにします。

この中期から長期の移行計画の 2 番目のステップは、以下の通りです。

図 2. プレゼンテーション層とデータ層が中間層から分離されました

図 2. プレゼンテーション層とデータ層が中間層から分離されました

次に、ASP ページおよび ASPX ページの両方を呼び出すことができる、より洗練されたプレゼンテーション層を利用できるようになります。恐ろしく機知に富んだことを行う必要はありませんが、.NET で強化されたサブシステムがどのような機能を公開しているのか、さらに COM(+) コンポーネントが依然として用意している機能にはどのようなものがあるのかを認識してください。

バックエンドのデータプロバイダは変更されていません。管理されないコードでは OLE DB を使用し、.NET ソリューション内からは新しく管理されるプロバイダを使用します。

最後に、この移行プロセスの 3 番目の段階として、2 つの中間層の機能を 1 つのビジネス層にマージする必要があります。しかし、これを行うためには、すべてのビジネスロジックやデータアクセス戦略の実装を再考する必要があります。これを行うと、移行プロセスは完了します。これを行う方法を一般化することは容易ではありません。そのすべてとは言いませんが、大部分がユーザーが作業している固有のアーキテクチャやコンテキストに依存しているためです。

.NET の領域では ADO について話す必要がありますか ?

この段階的な移行の主な利点は、.NET のスキルを身に付け、微調整するために必要な時間をとることができることです。

.NET アプリケーションから ADO オブジェクトを使用することは、間違いなく可能です。.NET アプリケーションに ADO COM オブジェクトをインポートするために、Run-time Callable Wrapper (RCW) を使用します。RCW は、COM から .NET を利用する CCW の反対の動作を行います。これを行うと、ネイティブの ADO インターフェイスを使用して、ADO レコードセット、コマンド、およびカーソルを操作できます。

この結果、ユーザーが所持しているいくつかのコードを再利用できますが、好ましくない副作用が生じるかもしれません。それは、時代遅れで、非効率的で、それほど機能的ではなく、さらに本質的によりスケーラブルで相互運用可能な ADO.NET のアーキテクチャを利用できません。つまり、単に何かができるだけで、それをする必要があるという意味ではありません。

従って、このセクションの先頭の質問、「.NET の領域に移行した後、ADO について話す必要がありますか ?」に対する答えは「いいえ、ありません。」ということです。明らかに必要でない限り、不要です。次回のコラムでは、この特別なトピックについて考えるつもりです。

詳細情報

より基礎的な情報については、ADO+ が導くデータアクセスの進化または Introducing ADO+: Data Access Services for the Microsoft .NET Framework をご覧ください。

Dino Esposito は Wintellect に勤務していて、そこで ADO.NET と ASP.NET のトレーニングとコンサルティングを行っています。彼は VB-2-The-Max の共同設立者で、MSDN Magazine に Cutting Edge コラムを連載しています。