きよくらの備忘録

「三日坊主と呼ばせない!日記」改め。主にソフトウェア開発関連の話題。

クラシックASP to Rasor (1)


2011/08/27に開催されたTech Party 2011 広島会場にて、後援させていただいた『新しい「ASP.NET Web Pages」を触ってみた − Classic ASP to Razor !? −』のフォローアップです。こちらもご一読ください。


あらかじめお断りしておきますが、前エントリでも書かせていただいている通り、今回の本題は「Classi ASP to Razor」です。このフォローアップも、基本的にはその点のみに絞って書いていこうと思います。
ご了承ください*1


早速それぞれの話題に入っていきたい…ところですが、最初に一つだけ、当日のセッションでも触れるのを忘れていた点について、追加で補足します。

前提条件

クラシックASPからの移植が今回の主題です。移植の難易度や手段を検討する際、そのASPソースコードについて、やはりある程度の前提条件は必要だと思います。今回その前提条件として以下を想定しています。

  1. クラシックASPとして正しく動作している
  2. クラシックASPとして(それなりに)健全なソースである

一つ目は言わずもがな、当然ですね。問題は二つ目です。一口に健全といっても「何が健全で何が不健全か」は判断が難しいかもしれません。…かもしれませんが、例えば私が今まで実際に遭遇した例でいうと、『1つの.aspファイルに30画面分のHTMLが埋め込まれていてIf ~ ElseIF ~で切り分けられている』というものがあったのですが、個人的にはこれはあまり健全なソースではないと思っています。



ASPとしても『ソースコードがグチャグチャでどうしようもない』とか『構成が複雑怪奇でメンテナンスができない』ようなものを仮にそのままWeb Pagesに移植できたとしても、どれはそのままでしょう。決して『今後継続してメンテナンスしやすい状態』にはならないと思います。



恐らく多少ソースがグチャグチャしていたり、複雑怪奇な構成になっていたりするものであっても、ASPでできる範囲のことであれば、Web Pagesに移植は可能だとは思うのですが、やはり移植した後のことも考え、ある程度のリファクタリングは事前に行ったほうが無難かもしれません。



これはこの”クラシックASP to Razor”特有の話ではなく、近い筋の話だと”VB6 to VB.NET”でも同じようなことがあったと記憶しています。ですので、そういった点でつまずいた場合は、ひょっとしたら以下のドキュメントに参考になる部分があるかもしれません。
Visual Basic 6.0 ユーザーのための Visual Basic .NET 移行ガイド


さて、前置きはこの辺りにして本題に…と行きたいところですが、今日はここまで。次回から、各ポイントについて具体的に書いていきたいと思います。

*1:もちろん、誤りや誤解を招くような表現がある場合は補足・訂正させていただきますので、そのような点があればぜひ、ご指摘ください。よろしくお願いします