さて、それは何かというと「.NET Framework」であるということです。

◎.NET Framework、開発運用してますか？
何をいまさらとおっしゃる方も多いと思いますが、現状 .NET Framework を活用したシステムを開発運用されている方はどれだけいるのでしょうか？
マイクロソフトの方々は「事例はたくさん出てきていますよ」とか「○○というところでは、こんなことをしています」などの話をよくされますが、それは「手厚く保護された企業」の話であって、末端の開発者などの話はあまり聞かれません。
例えば、Visual Basic 6.0 の開発者はたくさんいますし、しかも Visual Basic 6.0 で開発されたアプリケーションも非常にたくさんあり、よく使われているなというのが肌でわかります。

しかし .NET Framework のテクノロジーを使った業務アプリケーションの話はあまり聞かれません。
確かに Visual Studio 6.0(Visual C++, Visual Basic, Visual InterDev, Visual J++) はマイクロソフトの開発ツール史上、最長のものであったため一番利用されているというのは事実であります。
ですが、少なくとも .NET Framework が世に出てから 2 年は経過しているので、もう少し普及しても良かったのではと思っています。

◎移行の難しさを越えて
では、何が問題だったのでしょうか？
マーケティングの失敗？テクノロジーの未成熟？日本の企業体質？等など、たくさんあげようと思えばいくらでもあげられると思いますが、その中でも「難しい」ということがあげられるのではないでしょうか？
難しいと言われている方の大半が Visual Basic から Visual Basic .NET に移行された方々で、Visual Basic から Visual Basic .NET へは一部進化（継承できるようになった、メモリ管理からの開放、等など）している部分もありますが、退化（エディット&コンティニュができなくなった、プロジェクトを保存しないとアプリケーション開発ができない、等など）してしまった部分もあり、かなりの方々が混乱してしまったというのが実情だと思います。
また、 .NET Framework を使う理由が、Visual Studio 6.0 のサポート切れを理由にされている方が多いということを考えると、サポートの問題に目をつぶれば、何もわざわざ .NET Framework で作り直す理由がないということになります。そのため、大半の開発者は、 .NET Framework の存在は知っているが、 .NET Framework を使うことがなく今までのテクノロジーで開発をされているということになっています。

では、なぜ .NET Framework のテクノロジーが必要になってくるのでしょうか。

次期バージョンである SQL Server “Yukon” をいち早く利用してみたいと考えている方は開発者に限らず運用者でも .NET Framework のテクノロジーが必要になってきます。
データベースの規格である SQL99 でオブジェクト指向に対応するべく新たな機能が盛り込まれました。
その具体的な例が Java VM の搭載です。しかし、皆さんもご存知のとおりマイクロソフトは Java VM は使いません。それの答えが .NET Framework との融合でありました。
SQL Server “Yukon” では .NET Framework 上で動く CLR を動かすことができますので、 .NET Framework 対応言語で開発すれば、今までの Transact-SQL では実現不可能であった高度なビジネスロジックを実装することが可能ですので、開発者は 1 つは .NET Framework 対応言語の習得が望ましいことになります。
また、運用者は開発者が作成した CLR を SQL Server “Yukon” に登録したり、パフォーマンスをチェックしたりすることになると思いますので、少なくとも .NET Framework のアーキテクチャを理解する必要があります。

これだけだと新機能を使わなければ「別に習得する必要はなし」という結論に達してしまうかも知れませんが、SQL Server “Yukon” は SQL Server 7.0/2000 にはない機能がたくさんあり、移行を計画する価値はあると思います。特に開発者の方々には福音はたくさんあると思います。しかし、運用者に関してはまだベータ版ということもあるので、本当にメリットが多いのかは示すことができませんが、パフォーマンス改善やメンテナンス系コマンドのオンライン化など細かなフィーチャーとして上げられていますので、期待できます。

ということで .NET Framework に慣れ親しんでもらうにはどうしたらよいのかというのを考えた上で、PASSJ 的に、データベースアプリケーションを開発する上で一番重要な ADO.NET についての講演を行うことを考えました。

◎ADOとADO.NETの違いからスタート
ADO.NET という名前は ActiveX である ActiveX Data Object(ADO) から名前を引き継いでいるので、なんとなくご存知の方はたくさんいらっしゃると思いますが、ADO と ADO.NET はまったく別物です。
ADO は基本的にデータベースと密接に接続されているという設計思想ですが、ADO.NET の設計思想は非接続であるということに尽きます。
接続型と非接続型では、データの一貫性、ロック、トランザクションなどの考え方がまったく違います。
ADO で開発されてきた方が一番戸惑うのがこの部分ではないかと考えています。

例えば、非接続型の場合(ADO.NET)、どのようにデータの整合性を保つのかというのが、一番問題になってきます。
データベースには基本的にデータの一貫性を保つ機構はありますが、それはデータベースとアプリケーションが密接に接続されている場合にのみ利用可能です。
では、非接続型の場合はどのようにデータの整合性を保つのでしょうか？
方法は 2 通りあるとおもいます。

1 つめは楽観的な方法として、そのレコードを特定できる条件を条件式に含め、その条件で更新・削除できなければ、そのレコードは誰かに更新されているということで、エラーにしたり、ユーザに通知したりする方法。
2 つめは悲観的な方法で、誰かがそのレコードを参照している場合には、そのレコードを参照させないなどのロジックを自前で実装して、整合性を保つという方法です。

ADO.NET のウィザードを使用すると、上記の 1 つめの方法を取るようにウィザードが自動的に生成してくれます。
しかし、このウィザードには落とし穴があります。
更新・削除などで生成される SQL 文は、参照するすべての項目を条件して生成されますので、大量のデータを取り扱う場合には非常にレスポンスが悪いということがいえます。
＜例＞
       SELECT title_id, title FROM titles
                    ↓
       UPDATE titles SET title_id = @tnew_itle_id, title = @new_title
       WHERE title_id = @old_title_id AND title = @old_title

※ WHERE 句に指定されている項目にインデックスが適切に設定されていなければ、
     パフォーマンスが悪くなる一例

こういったことは、やってみないとわからないですし、正しく解説されたドキュメントを読まなければ、はじめての方には何のことだかさっぱりわからないと思います。

Visual Studio .NET を利用する場合、非常に高い生産性をあげることができますが、それが高パフォーマンスなのかというとそうではないということを理解していただきたいと思います。

◎次世代に必要なテクニックを！
私のセッションでは、こういったことを具体的に解説し、正しい ADO.NET の活用方法を身につけていただきたいと思っています。

また、セッションに時間があれば、次世代 ADO.NET V2.0 の紹介を行い、 SQL Server “Yukon” 時代にスタートダッシュが切れるようにお手伝いをしたいと考えております。では、会場でお会いしましょう！

（2004/01/08）