ASP.NETページの実体はPageクラスのオブジェクトである。ASP.NETを理解するには、このクラスのプロパティとメソッドを習得するのが早道。
前回簡単に解説したように、ASP.NETページを開くと暗黙的にSystem.Web.UI.Pageクラスのインスタンスが生成される。ASP.NETページにとってPageオブジェクトは、ウィンドウ・アプリケーションにおけるウィンドウに相当し、ボタンやテキスト・ボックスといったユーザー・インターフェイスを始め、すべてのビジュアル要素はPageオブジェクトの一部として管理される。また、Pageクラスはサーバとクライアントをつなぎあわせる、情報交換の場としても機能する。こうして考えると、PageオブジェクトがASP.NETページにおけるアプリケーション・オブジェクトそのものであるといってもいいだろう。
とはいえ、これまでに紹介してきたサンプル・プログラムには、Pageクラスが明示的に現れてはいない。これは、scriptエレメント内部に定義されるすべてのメソッドと変数は、暗黙的にPageクラスから派生して定義されるクラスのメンバとなるため、明示的にクラスを定義する必要はないからだ。
ただ、明示的にPageクラスの派生クラスを定義して、これをASP.NETページに対応付けることも可能だ。このためには、いままで1つのaspxファイルに記述していたコードとビジュアル要素を2つに分割し、aspxファイルにはビジュアル要素だけを記述し、プログラム・コードは独立したソース・コード・ファイルに記述する必要がある。このように、ファイルを分割する仕組みはコードビハインド(code-behind。「behind」は「背後で」「隠れて」という意味)と呼ばれている(ちなみに日本語のリファレンス・マニュアルでは、『分離コード』と表記されている)。
例えば、リスト4.1(sample01.aspx)は、これまでに示したとおりに、プログラム・コードとビジュアル要素の両方が含まれるaspxファイルである。
<%@ PAGE LANGUAGE="C#" %>
<html>
<script runat="server">
void Page_Load(object sender, EventArgs e) {
textEMail.Text = "hoge@atmarkit.co.jp";
}
</script>
<body>
<form runat="server">
<asp:TextBox id="textEMail" runat="server"></asp:TextBox>
</form>
</body>
</html>
これがコードビハインドによって、リスト4.2(sample02.aspx)に示すaspxファイルと、リスト4.3(sample02.aspx.cs)に示す.csソース・コード・ファイルに分割することができる。sample01.aspxとsample02.aspxのどちらへアクセスしても、まったく同じように処理が実行され、テキスト・ボックスに文字列が入力される。
<%@ PAGE LANGUAGE="C#" Inherits="UnnamedPage" Src="sample02.aspx.cs" %>
<html>
<body>
<form runat="server">
<asp:TextBox id="textEMail" runat="server"></asp:TextBox>
</form>
</body>
</html>
public class UnnamedPage : System.Web.UI.Page {
protected System.Web.UI.WebControls.TextBox textEMail;
private void Page_Load(object sender, System.EventArgs e) {
textEMail.Text = "hoge@atmarkit.co.jp";
}
}
これらのリストを見れば分かるように、コードビハインドによる分割は、基本的にscriptエレメントに記述したコードをソース・コード・ファイルに抜き出し、それ以外のビジュアル要素をそのままaspxファイルに残すことによって実行される。
ただし、aspxファイルから分離されたソース・ファイルを関連付けるために、「@Pageディレクティブ」にInherits属性とSrc属性を追加する必要がある。Inherits属性にはPageクラスから派生して定義したクラスの名前を、Src属性にはそのクラスが定義されているソース・ファイル名をそれぞれ指定する。ソース・ファイルの名前には、
<aspxファイルの名前>+.cs(Visual Basic .NETなら.vb)
を指定するのが慣例となっているようだが、まったく関連のない名前を付けても不都合はない。
一方ソース・コード・ファイルでは、Pageクラスの派生クラスを定義し、このメンバとしてscriptエレメント内部に記述していたメソッドやプロパティを定義する。またこれに加えて、ソース・コードからアクセスしたいビジュアル要素がある場合には、これに対応するプロパティも定義する必要がある。リスト4.2に示す例では、sample02.aspxに含まれているテキスト・ボックスへアクセスするために、System.Web.UI.WebControls.TextBoxクラスのプロパティtextEMailを定義している。
こうして定義するプロパティの型(クラス)はaspxファイルに記述したサーバ・コントロールのタイプによって決まり、そのクラス名はWebサーバ・コントロールならばコントロール名から「asp:」を取り除いた名前(例:asp:TextBoxならばTextBox)に、HTMLサーバ・コントロールならばコントロール名がそのままクラス名に対応している。
なお、Webサーバ・コントロールに対応するクラスはSystem.Web.UI.WebControls名前空間で、HTMLサーバ・コントロールに対応するクラスはSystem.Web.UI.HtmlControls名前空間でそれぞれ定義されている。またプロパティ名は、サーバ・コントロールのid属性値に一致させて指定する。こうしてプロパティを定義しておけば、プロパティへの操作がサーバ・コントロールへと自動的に反映されるようになる。
また、aspxファイルのscriptエレメントにコードを記述するときには、下表に示す名前空間がデフォルトでインポートされているため明示的に設定する必要がなかったが、コードビハインドによって分離されたソース・コード・ファイルでは、usingディレクティブを使って明示的にインポートするか、System.Web.UI.Pageのように完全限定名を指定しなければならない。なお、scriptエレメント内部で下表にない名前空間のクラスを参照するには、「@Importディレクティブ」を使って、名前空間のインポートを行う。
System
System.Collections
System.Collections.Specialized
System.Configuration
System.IO
System.Text
System.Text.RegularExpressions
System.Web
System.Web.Caching
System.Web.Security
System.Web.SessionState
System.Web.UI
System.Web.UI.HtmlControls
System.Web.UI.WebControls
scriptエレメント内部で、デフォルトでインポートされる名前空間の一覧
ところで、いままでどおりコードとビジュアル要素の両方をaspxファイルに記述しても、両者の分離は十分実現されているにもかかわらず、さらに2つのファイルへ分割するメリットはどこにあるのだろうか。
メリットの1つは、ページ・デザインとコーディングの分業が容易になることだが、それだけではない。分割によってソース・コードを公開することなく、Webアプリケーションの配布が可能になるのである。ASPのような従来のサーバ・サイド・スクリプト環境では、ビジュアル要素とソース・コードを1つのファイルにまとめて記述しなければならなかったため、Webアプリケーションのデベロッパーとユーザー(アプリケーションをホストする組織)が異なる場合でも、ソース・ファイルがユーザーの目に触れざるをえなかったが、ASP.NETではビジュアル要素だけを記述したaspxファイルと、バイナリ・ファイルであるアセンブリを配布するだけで済む。
ただ、そのためには手作業でソース・コードをコンパイルし、アセンブリを検索パスのどこかへ格納しておく必要がある。例えば、以下のコマンドを実行してコンパイルしたら、生成されたアセンブリsample02.aspx.dllを仮想パス“/bin”に対応するディレクトリ(例:c:\inetpub\wwwroot\bin)へ格納する必要がある。ただし、Webアプリケーション(sample02.aspx)が仮想ディレクトリの中に格納されている場合には、仮想ディレクトリの直下にあるbinディレクトリへアセンブリを格納する。
csc /t:library sample02.aspx.cs
なお、こうして手作業でコンパイルする場合には、@PageディレクティブにSrc属性を指定する必要はない。Inherits属性にクラス名が指定されてさえいれば、自動的にこのクラスを含むアセンブリが検索される。
以上の利点があるコードビハインドだが、開発環境を使わなければコンパイルが面倒であるし、サンプル・プログラムを示すには不向きであるため、本連載では基本的にこれまでどおりコードビハインドを行わず、aspxファイルにコードを含めて示していくことにする。
Copyright© Digital Advantage Corp. All Rights Reserved.