アーキテクチャの変更のポイントを知っておくとVisual Basic .NETになったときに、スムーズな移行ができます。また、Visual Basic 6.0でどのようなアーキテクチャを選択しておけばよいかという指針が見つかります。
ここでは、Visual Basic 6.0のユーザーを対象に、「Visual Basic .NETへの移行」にフォーカスしたVisual Basic .NETの特徴を紹介していきます。
■ 変更ポイント
Windows/Webアプリケーションをどのように作成するようになるのか、またコンポーネントはどうなるのか、といった変更ポイントを紹介します。
■ アップグレードウィザードによる変更点
アップグレードウィザードがどのような変更を加えてくれるかを紹介します。
■ 今、何をしておくべきか？
Visual Basic .NETでの変更に備えて、現在開発中のVisual Basic 6.0のプロジェクトをどのように構成しておけばよいかの指針を紹介します。
■ 関連・補足項目
各項目に関連する開発上のヒントや補足事項を紹介します。
1. Windowsアプリケーション
- Windowsアプリケーションは.NETでも作成可能
- Windowsフォームに自動的にアップグレード
■ 変更ポイント
Windowsアプリケーションは、Windowsフォームをベースに作成します。ユーザーインターフェイスは、WindowsコントロールやGDI+を利用して整えます。.NETコンポーネント（クラスライブラリやコントロール）を利用することもできますし、XML Webサービスを利用することもできます。
また、従来のCOMコンポーネント（コードコンポーネントやActiveXコントロール）を利用することもできます。ただし、COMと.NETの相互運用にはその境界を越えるためのオーバーヘッドが生じることを考慮に入れる必要があります。
なお、フォームおよびコントロールの変更の詳細は、第5章を参照してください。
■ アップグレードウィザードによる変更点
Visual Basic 6.0で作成されたWindowsアプリケーションは、アップグレードウィザードによってアップグレードすることができます。アップグレードするためには、Visual Basic 6.0のプロジェクトであることが必要です。それ以前のバージョンのVisual Basicで作成されたプロジェクトは、あらかじめVisual Basic 6.0にアップグレードしておきます。
Visual BasicのフォームはWindowsフォームに、また、フォーム上に配置されたコントロールも、可能な限り対応するWindowsコントロールにアップグレードされます。対応するものがないときには、アップグレードレポートとコメントに従って修正を行なう必要があります。これらの詳細は、第5章を参考にしてください。
COMコンポーネント（コードコンポーネントやActiveXコントロール）を利用しているアプリケーションもアップグレード可能です。このとき、相互運用のためのラッパーが作成され、必要な参照設定が自動的に追加されます。なお、COMコンポーネント自体のアップグレードについては、本章の「コンポーネント」を参照してください。
■ 今、何をしておくべきか？
Visual Basic 6.0では、簡単にリッチなユーザーインターフェイスを備えたWindowsアプリケーションを作成することができました。これらを、ウィザードを利用して容易にVisual Basic .NETにアップグレードできます。また、COMコンポーネントを利用していても問題はありません。簡単にアップグレードできるからです。問題がないどころか、COMコンポーネントをできるだけ利用することをお勧めします。COMコンポーネントなどを利用して、ユーザーインターフェイスとビジネスロジックをできるだけ分けて、アプリケーションを作成しておきましょう。そうすれば、.NETにアップグレードする時、COMコンポーネントを対応する.NETコンポーネントに部分的に置き換えたり、あるいはコンポーネントはそのままで、それを利用する側のプログラムを置き換えたりするなど、柔軟に対応することができます。
● Plus One
Visual Basic .NETでは、Windowsアプリケーションと同じくらい簡単に、Webアプリケーションを作成できます。残念ながら、既存のWindowsアプリケーションを自動でWebアプリケーションにアップグレードするツールはVisual Studio .NETにはありません。
しかし、Windowsアプリケーションをアップグレードすることで、コードが.NETに対応するよう書き直されるので、これをコピー＆ペーストして新しいWebアプリケーションのプロジェクトで活用するという方法は有効でしょう。
もちろん、すべてをWebアプリケーションにする必要はありませんし、Webアプリケーションに向かない場合や、移植が非常に困難な場合があります。以下にその例を示します。
複雑なユーザーインターフェイスを持つアプリケーション
ラベルやテキストボックスなど、標準コントロールを利用した簡単なユーザーインターフェイスを持つアプリケーションはWebアプリケーションへの移行も簡単に行なえます。しかし、複雑なインターフェイスや、サードパーティ製のコントロールを利用したアプリケーションはアップグレードが困難な場合が多く、また、Webアプリケーションに向かない場合も多いでしょう。
イベントを継続して利用するアプリケーション
Webフォームは、サーバーコントロールを利用するため、マウスの移動やドラッグなど継続的にイベントを取り続けたいアプリケーションなどは、向いているとはいえません。このような場合、DHTMLなどを利用することも可能ですが、この変更は簡単にはできません。
以上のようなアプリケーションは、そのままWindowsアプリケーションとして利用することをお勧めします。
また、このアップグレードをできるだけ簡単にするために、Visual Basic 6.0のプロジェクトにおいて、ユーザーインターフェイスとビジネスロジックを分けて作成しておくこと、また、できるだけユーザーインターフェイスを薄く作っておくことをお勧めします。
2. Webアプリケーション
- ASP.NETを利用したWebアプリケーションの開発
- 使い慣れた開発環境と言語で実現可能
- 移行が簡単なのはASP＋COMコンポーネント
■ 変更ポイント
これまでは、Visual Basic 6.0だけでは、Webアプリケーションを作ることが難しかったので、Visual Basic 6.0でコンポーネントを作り、それをASPから呼び出して利用したり、ユーザーインターフェイスはDHTMLを利用したりしていました。つまり、Visual Basicの活躍の場が、中間層の作成のみに限定されていました。
これからは、Visual Basic開発者は、いつもの使い慣れた開発環境と言語を使ってWebアプリケーションを開発することができます。
Visual Basicに限らず、.NETでは、Webフォームを利用することができます。Webフォームには、「HTMLベースのユーザーインターフェイス定義」と「イベント処理などのロジック」の両方が含まれます。これを同じファイルに記述することも、ロジック（コード）を別のファイルに記述して、「ページの背後のコード（コードビハインド）」として提供することもできます。
Visual Basic .NETで、「ASP.NET Webアプリケーション」プロジェクトを作成すると、あらかじめ「WebForm1.aspx」と、コード用のファイル「WebForm1.aspx.vb」が作成されます（図1）。.aspファイル内の「runat=”Server”」の記述のあるフォームやコントロールと、.vbファイル内のコードは、ASP.NETランタイムエンジン、つまりサーバーサイドのエンジンにより実行されます。このように、Webフォームを利用したアプリケーションは、基本的にサーバーベースのアーキテクチャを採用しています。とはいえ、Visual Basic .NETでは、フォームにコントロールを貼り付け、それにイベントプロシージャを実装する感覚でデザインしていくことができます。
Visual Basic .NETでは以下の3種類のコントロールを利用できます。
・HTMLクライアントコントロール
・HTMLサーバーコントロール
・Webサーバーコントロール
HTMLクライアントコントロールは従来からある、いわゆるタグに1対1で対応する、ブラウザ（クライアントサイド）で実現されるコントロールです。
HTMLサーバーコントロールも、いわゆるタグに1対1で対応するコントロールですが、サーバーサイドで実現されます。そのためサーバー側のコードと連携することが可能です。また、HTMLで実現している既存のページをサーバーベースに移行するためにも利用できます。
Webサーバーコントロールは、HTMLコントロールより多くの機能を提供し、以下のような特徴を持ちます。
・Visual Basic開発者にとって使い慣れたオブジェクトモデル
・ブラウザを検出し、ブラウザに最適の出力を調整する
・適切なHTMLを生成し、ユーザーインターフェイスを実現する
これらにより、強力なWebアプリケーションのプレゼンテーション部分をVisual Basicで作ることができるようになったというわけです。
ASP.NETを利用したWebアプリケーションを作成するためには、Visual Basicのアプリケーション開発のノウハウだけでなく、Webの開発知識（HTML、DHTML、XMLの基礎知識、セッション管理の考え方、クライアントサイドスクリプトなど）も必要です。もちろん、ASP.NETの技術習得も必要です。これにはかなりのページを費やすのでここでは解説できません。ASP.NETについては、本誌2002年2月号の別冊付録なども参考にしてください。
■ アップグレードウィザードによる変更点
Visual Basic 6.0では、Webアプリケーションを作成するためのプロジェクトタイプがいくつかありました。しかしそれらのほとんどは、アップグレードウィザードによって簡単にアップグレードできるというわけではありません。
アップグレードされないプロジェクトは、
・DHTMLアプリケーション（DHTML＋クライアントサイドDLL）
・ActiveXドキュメント
です。これらは、クライアントベースのアーキテクチャを使っているため、根本的にサーバーベースのアーキテクチャを持つASP.NETに、自動でアップグレードされません。また、手動での変更も簡単ではありません。
また、
・IISアプリケーション
は、ウィザードによってWebクラスがASP.NETにアップグレードされます。しかし、手動での修正が必要となるでしょう。
■ 今、何をしておくべきか？
Visual Basic 6.0を利用してWebアプリケーションを作成するときの技術として、
- クライアントサイド
HTMLとクライアントサイドスクリプト - サーバーサイド
ASP、COMコンポーネント（ここをVisual Basic 6.0で作成）
を利用していれば、スムーズな移行が可能です。
移行の段階には、ASPから.NETコンポーネントを利用することもできますし、COMコンポーネントをASP.NETから利用することもできます。
結論として、Visual Basic .NETへの移行を意識してWebアプリケーションを作成するなら、Windowsアプリケーションの時と同様、できるだけCOMコンポーネントなどを活用し、機能を分割して作成しておくとよいでしょう。そして、ユーザーインターフェイスをDHTMLとASP、コンポーネントの呼び出しをASP、ビジネスロジックをCOMコンポーネントで作成しておくことをお勧めします。これにより、既存の資産を活用し、スムーズな移行を実現することができます。
3. コンポーネント
- .NETコンポーネント
- クラスライブラリ（コードコンポーネント）
- Windowsコントロール、Webコントロール
- コードコンポーネントは自動アップグレード
- ユーザーコントロールは自動アップグレード不可
■ 変更ポイント
Visual Basic 6.0では「ActiveX DLL」「ActiveX EXE」「ユーザーコントロール」の各プロジェクトでCOMコンポーネントを作成してきました。Visual Basic .NETでは、このCOMコンポーネントに代わるものとして、.NETコンポーネントを作成することができます。
.NETコンポーネントを作成するためには、プロジェクトのテンプレートとして、「クラスライブラリ」あるいは「Windowsコントロールライブラリ」を選択します。
「クラスライブラリ」プロジェクト
Visual Basic 6.0の「ActiveX DLL/EXE」に対応するプロジェクトを作成するには、プロジェクトのテンプレートとして、「クラスライブラリ」を選択します（図2）。このタイプを選択すると、Visual Basic 6.0のクラスモジュールにあたるClass1.vbというファイルがひとつ用意され、ここに次のようなコードが自動的に追加されます。
Public Class Class1
End Class
このClass…End Classに、プロパティやメソッド、イベントを実装していきます。このファイルは厳密にはVisual Basic 6.0の「クラスモジュール」とは異なります。Visual Basic .NETでは、「ひとつのファイルに複数のクラスを記述」できるからです。Class…End Classの記述がそれを可能にしています。もちろん、従来通り1つのファイルに1つのクラスのみを記述するということも可能ですが、複数のClass…End Classをファイルに追加することで、複数のクラスを1つのファイルで提供し、ファイル数を減らすことができます。
メソッドやイベントについては、その実装方法はほとんど同じです。プロパティの記述はわかりやすく変更されました。第4章の「プロパティプロシージャ」を参照してください。
従来3つだったスコープ（Private、Friend、Public）に新たな概念が追加されました。
追加されたキーワードは、Protectedで、これは「コードの継承」の機能追加によるものです。
「Windowsコントロールライブラリ」プロジェクト
コントロールを作成するには、プロジェクトのテンプレートとして、「Windowsコントロールライブラリ」を選択します（図3）。このタイプを選択すると、Visual Basic 6.0のユーザーコントロールモジュールにあたるUserContorl1.vbというファイルがひとつ用意され、ここに以下のようなコードが自動的に追加されます。
Public Class UserControl1
Inherits System.Windows.Forms.UserControl
Region ” Windows Form Designer generated code “
（略）
End Region
End Classユーザーコントロールは、UserControlから継承して作成します。また、#Region…End Regionまでには、ユーザーインターフェイスを提供するためのコードが必要ですが、Visual Basic .NETではデザイナにより生成させることができます。
「クラスライブラリ」で解説した変更以外の変更点は、マニュアルなどを参考にしてください。
この他、Webコントロールを作成するためには、「Webコントロールライブラリ」プロジェクトを選択します。
■ アップグレードウィザードによる変更点
Visual Basic 6.0で作成した「ActiveX DLL/EXE」プロジェクトは、.NETの「クラスライブラリ」に自動変換されます。ただ、今まで、クラスのプロパティで設定していたことが、属性としてコードに含めることができるようになったものについては、手動で変更が必要です。たとえば、トランザクションの設定などがそれにあたります。
また、ユーザーコントロールのプロジェクトはアップグレードすることができません。
ユーザーコントロールに変更を加えたい場合は、2つの選択肢があります。ひとつは、Visual Basic 6.0を使用してユーザーコントロールを変更し、それをCOMと.NETの相互運用機能を利用して使用する方法です。
そしてもうひとつは、Visual Basic .NETでコントロールを新しく作り直す方法です。
これはもちろん大変ですが、Visual Basic .NETならではの新しい機能（動的プロパティの設定など）を利用できます。
● Plus One
XML Webサービスの作成
コンポーネントとして提供してきた機能を、XML Webサービスに置き換えて提供してもよいでしょう。
これにより、ファイアウォールを越えたメソッド呼び出しが可能になります。また、データの受け渡しにはXMLが利用されるため、他の言語やプラットフォームとのやり取りがグンと楽になります。
ただし、トランザクションなど、一部サポートされない機能もあります。また、パフォーマンスについても考慮が必要です。
結論としては、トランザクションなどを必要としない、他のプラットフォームと相互運用が必要なケースでは、中間層をXML Webサービスにすることを考慮してもよいということがいえます。
ただし、もちろんこの変更は手動になります。
いったんVisual Basic .NETでコードを.NETにアップグレードしておき、そのコードを「ASP.NET Webサービス」プロジェクトにコピー＆ペーストして活用すると作業が楽になります。
統合デバッガ
統合デバッガにより、COM+コンポーネントの開発サポートが改善されました。ステップインでクライアントとCOM+コンポーネントのデバッグが可能になりました。
さらに、Visual Basic 6.0のCOM+コンポーネントへもステップスルー可能です。ただし、最適化なしの、シンボリックデバッグ情報が必要です。
4. データアクセス
- .NETではADO.NETを利用
- 分散アプリケーションに適したモデル
- XMLに強力に対応
- ADOとADO.NETはコントロールとのバインドが可能
■ 変更ポイント
Visual Basic .NETでは、.NET Frameworkが提供するデータアクセスのためのライブラリであるADO.NETを利用できます。これは、アプリケーションが今まで以上に分散し、企業を超えて、企業間でひとつのアプリケーションを構成する場面などを想定しています。そのため、データソースに常に接続していない、いわゆる「非接続型のデータアクセス」にフォーカスしたモデルとして設計されています。同時に、XMLの機能が強化されていることも特徴のひとつです。さらに、分散アプリケーションで使用したときのパフォーマンスもADOと比べて改善されています。
WindowsフォームやWebフォームでは、ADO.NET（図4）や、それとバインドするためのDataGridコントロールなどを利用することができます。
- DataSet
ADO.NETの最も重要なクラスで、データをキャッシュして利用するために使います。
ADOのRecordsetオブジェクトの機能のうち、分散アプリケーションにおいて必要な「非接続型のデータアクセス」を意識したオブジェクトであることがDataSetの特徴です。 - OleDbXXX
「OleDb」で始まるクラスは、OLE DBプロバイダ経由のデータアクセスを実現します。 - SqlXXX
「Sql」で始まるクラスは、直接SQL Serverにアクセスすることができます。
DataGridコントロールにバインドされたデータを、Windowsフォームでは読み書き両用に使えますが、Webフォームでは読み取り専用となります（もちろん相応のコードを書けば、Webアプリケーション上でもデータの更新は可能です）。
Visual Basic .NETでも、ラッパークラスを利用して従来のDAOやRDOやADOも利用可能ですが、COMと.NETのオーバーヘッドがあります。また、ADO.NETと同様のデータバインディングが可能なのは、ADOだけです。
■ アップグレードウィザードによる変更点
コードのアップグレード
DAO、RDOを利用しているVisual Basic 6.0のプロジェクトをアップグレードすると、ラッパークラスが自動的に生成され、それを利用して動作するアプリケーションになります。またADOを利用しているプロジェクトは、システムが提供するADO2.7用のラッパークラス（「Primary Interop Assembly」として提供）を利用するアプリケーションにアップグレードされます。つまり、いずれも特別なコードの変更は不要です。
コントロールのアップグレード
データコントロール（DAOのデータコントロール）はアップグレードされずにエラーを表わす「赤い色のラベル」に変更されます（アップグレードしたときに対応するコントロールがないと、多くの場合この赤色のラベルになります）。
また、RDC（RDOのデータコントロール）はラッパークラスが生成されますが、コントロールへのデータのバインディングはできません。
ADODC（ADOデータコントロール）はVisual Basic 6.0の互換機能として提供されるADODCに置き換えられます。また、バインドしていたコントロール（データグリッドやデータリストコントロールなど）を利用している場合は、それらのためのラッパークラスが追加されます。バインディングの情報もそのままアップグレードされますので、特に修正をしなくてもそのままでアプリケーションが動作します。このままADODCを使うことも可能ですが、あくまでも、Visual Basic 6.0との互換のために用意さ
れたものであるため、将来に渡って存在が保障されるわけではありません。オーバーベッドを考慮する場合や、ADO.NETの機能を利用したい場合は、ADO.NET、および対応するコントロールやコンポーネントに置き換えるとよいでしょう。
■ 今、何をしておくべきか？
ADO.NETは、ADOに似ている部分もありますが、データへのアプローチやアプリケーション設計の方針が異なります。ですから、ADO.NETを利用したアプリケーションを作成する場合、既存のADOのコードを活用するよりも、ADO.NETでイチからコーディングをしたほうが、ADO.NETの特徴を生かしたアプリケーションが作成できるかもしれません。もちろん、データにアクセスするためのADOの知識が無駄になるわけではありません。むしろ、それと比較することでADO.NETの優位性が見えてきて、より
よいコードが書けると思います。実際多くのADO.NETのマニュアルはADOとの比較でそれを語っています。
そのような意味でも、Visual Basic 6.0で は ADOを利用してADOに 親しん で おき、.NETになったら、ADO.NETを利用することをお勧めします。
■ 関連・補足項目
ADO.NETについては、ぜひ別途習得してください。