連載 ASP→ASP.NET移行テクニック 第1回　ASP.NET移行へのプロローグ 山田　祥寛 2004/04/21
Page1 Page2 Page3

＜統合＞移行パターンの類型化

　上記では、広義での「移行」方法を3つのパターンに分類したが、その中でも＜統合＞パターンは、現時点での最も現実的な解であろう。今後、移行を進めていく中では多くの読者が＜統合＞パターンを前提に、さらなる細部の方針を定めていくことになると思われる。

　その＜統合＞移行パターン（以下、単純に「移行」と呼ぶ）は、さらに「水平移行」のパターンと「垂直移行」のパターンに大別することができる。

垂直移行と水平移行

○水平移行

　n層構造という言葉が定着して久しいが、Webアプリケーションは基本的に以下の3つの層（レイヤ）から構成されることが多い。ここでは、設計構造に関する詳細は解説しないが、興味のある方は別稿「アプリケーション・アーキテクチャ設計入門」などを参照してほしい。

レイヤ	概要
プレゼンテーション層	ユーザー・インターフェイスを管理
アプリケーション層	アプリケーションのコアな挙動、制御を管理する。ビジネス・ロジック層、ファンクション層とも呼ばれる
データ層	データベース・サーバなど、バックエンドのデータ・ストアを管理
3層構造の構成

　水平移行とは、1つの層の単位で移行を行うことをいう。例えば、プレゼンテーション層（ユーザー・インターフェイス）だけをASP.NETに移行するようなケースだ。ユーザー・インターフェイスは、アプリケーションの中でも最も変更頻度が多く、変更に際する手間も煩雑なことが多い。プレゼンテーション層をASP.NETに移行することで、パフォーマンスの向上のみならず、開発生産性・保守性の改善も期待できる。

　しかし、アプリケーション層との通信において、マネージ／アンマネージ・コードの境界越えが発生することからオーバーヘッドの発生が問題となる可能性がある。

○垂直移行

　垂直移行とは、ある機能の単位で全レイヤを置き換えることをいう。部分的とはいえ、全レイヤを置き換えるため、個々の機能の独立性が高い場合には、水平移行に比べると「境界越え」による問題は少ない。また、「境界越え」が少ないということは、結果的にASP／ASP.NET間で用意しなければならないインターフェイス開発も少なくて済む可能性がある。

　しかし、機能が密接に絡み合っている場合、「境界越え」のオーバーヘッドが無視できなくなる可能性はあるし、共有データ（アプリケーション・セッション変数）の授受についても十分に考慮する必要がある。

どの移行方式を選択するべきか？

　移行パターンを類型化したところで、読者諸兄が興味を持つのは、やはりこの点だろう。お題目は分かった。しかし、これから私たちはどのようにすればよいのか？ これについては、残念ながら一律な結論はない。あなたが置かれた状況、アプリケーションの特性、そのほかの外的要因によって、いずれの方式を行うかを決めるべきであり、その決定を下すのは、現場に立ったあなた自身なのだ。

　以下では、その指針となるべきポイントのみをいま一度まとめておくことにしたい。

移行方式		移行方式の採用ケース
＜共存＞		・現存のアプリケーションに特別な問題を感じていない
＜統合＞	共通	・移行の影響範囲が局所化できる ・パフォーマンスや保守のうえでの問題個所が明確に分析できている ・移行にかかるリスクやコストを最小限に抑えたい
	水平移行	・ある特定のレイヤの変更が頻繁に発生する ・境界越えによるパフォーマンスの劣化が致命的な要因にならない ・画面・機能間の依存関係が密接である
	垂直移行	・アプリケーション内の個々の機能が独立 ・既存のアプリケーションに新たな機能・画面を追加していきたい
＜置換＞		・移行の影響個所が広範囲にわたり、部分的な移行が困難 ・コスト・工数に十分な余裕がある
移行方式と採用ケース

　重要なポイントは、いずれの移行方式にも一長一短があるということだ。ここでぜひとも押さえておいていただきたいことは、「それぞれの方式における一長一短を理解し、レガシー資産に対する自己分析との照合を行うことが、移行の第一歩である」ということだ

ASP.NETへの無批判な＜置換＞が、必ずしも万人を幸せにするわけではない。

構造上の変更点

　さて、以上で移行に関する考え方を一通り理解したところで、いよいよ具体的な移行時のポイントを構文的な見地から見ていくことにしよう。

　移行とは、少ない工数でいかに新たなアーキテクチャの恩恵を最大化するかを目的とした作業である。拡張子を「.asp」から「.aspx」に変更しただけでレガシーASPがASP.NETに化けると考えてはならないが、（ページ・機能単位であるにせよ）1からコードを書き起こさなければならないとしたら、それはもはや移行とはいえない。置換だ。

移行とは、コードへの影響を最小限に抑えつつ、レガシーASPアプリケーションを新しいアーキテクチャに適用していくこと。

　そういった意味で、構文的な変更点を明確に把握しておくことは、ある意味、移行の第一歩であるといってよい。変更点を把握することで、移行時に変更すべきポイントにフォーカスして、コードの変更を行うことができるからだ。それでは、さっそく見ていこう。

INDEX
	ASP→ASP.NET移行テクニック
	第1回　ASP.NET移行へのプロローグ
	1．移行の3つのアプローチ
	2．＜統合＞移行パターンの類型化
	3．構造上の変更点

　

「ASP→ASP.NET移行テクニック」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）