第1回 軽量ASP.NET開発の概要とSQL Server Expressの準備：連載：ASP.NETによる軽量業務アプリ開発（2/3 ページ）

[arton， ]

埋め込みHTML開発の光と影と光

　直接ASPXファイルへプログラムを埋め込むというと、Web開発の歴史的な経緯を体験された方であれば、1990年代後半のJSP（JavaServer Pages）やASP（Active Server Pages）による無秩序な開発による混乱を想像されるだろう。

　これらの埋め込みHTML*2を利用すると、比較的短期間にWebアプリケーションを量産できる。その結果いろいろ問題点が判明した。

*2　HTMLを利用したテンプレート内にプログラムを埋め込むことから、「埋め込みHTML」と呼ぶ。

　埋め込みHTMLはその性格上、ファイル分割があまり考慮されないため、次の2つの問題が生じる。

• 1つのファイルにWebアプリのあらゆる処理が詰め込まれる

　　 → プログラムの見通しが悪い。特に意識しないと全ての変数がグローバルとして扱われることとなるため、バグが入りやすい

• 同じような処理が複数のファイルで繰り返される

　　 → 修正が必要となった場合の修正量が大きくなる。またそれによって修正漏れが生じやすい

　このような問題から、大規模なWebアプリ開発に秩序をもたらすものとしてMVCフレームワークが注目されることになり、現在のフレームワーク隆盛につながったといえる*3。

*3　ASP.NETのフォームベースのフレームワークは、WindowsデスクトップアプリのイベントドリブンモデルをWeb開発に持ち込むことでデスクトップ開発者がWeb開発に親しみやすくなるようにするためのものなので、埋め込みHTMLに対するアンチとしての意味合いはない。

　プログラムを適切な単位に分割して構成することは、それがMVCであろうと、MVVMであろうと文句なくよいことだ。分割して統治することがプログラムにおいても最重要課題であることは、すでに十分に語りつくされている。

　ただ、そこには、規模（プログラム数、開発者数）の問題と、コンピューターリソースの時代的な制約*4による問題があったことが無視されている。

*4　本連載では、最終的にC#とJavaScriptが異なる役割を果たす。これはWebブラウザー上のJavaScriptが実用的な速度で実行できるようになった現在だから可能なことだ。

　これらの問題がなければ、埋め込みHTMLそのものは、以下の点についてはMVC（あるいはMVVM）フレームワークより優れている。

• 学習コストがほとんどない

　　 → 開発に利用するプログラミング言語と最低限のWebアプリケーション用の追加APIのみで利用できる

• デプロイが容易

　　 → 埋め込みHTMLファイルをWebアプリケーション用ディレクトリへコピーするだけで設定できる

• 実行→修正が早い

　　 → 個人レベルの開発であれば、エディターによる埋め込みHTMLの修正とテスト実行を並行しながら進められる

　本連載では、以下の順番で軽量ASP.NET開発について説明する。

• SQL Server ExpressをASP.NETで利用するための準備方法（今回の内容）
  　　− SQL Server ExpressのASP.NETで利用するためのデータベースの作成方法を示す
• 埋め込みHTMLを利用したCRUD（Create／Read／Update／Delete）処理
  　　− 直接HTMLを作成するアプリケーションの開発方法を示す
• 軽量なWebサービスによるCRUD処理
  　　− UIとDBアクセスをHTML上のJavaScriptコードとASP.NET側のC#コードに分離する構成方法を示す

　それでは始めよう。今回は、準備段階としてSQL Server Expressのセットアップまでを解説する。

SQL Server Expressの準備

　上述したように、Web Platform Installerやコントロールパネルの［Windowsの機能の有効化または無効化］などを使用して、IIS（IIS Express）、ASP.NET 4.5、SQL Server Express 2008 R2をインストール済みであるとする。

　ここでは、ASP.NETからSQL Serverを使うための前提となる知識を説明する。結論としては、複数のWebアプリケーションや別に実行するプログラムでデータベースを共有する場合はSQL Serverのサービスにデータベースを管理させ、そうでなければWebアプリケーション固有のファイルとしてデータベースを管理させるのがよい。

ASP.NETからのSQL Serverの利用について

　ASP.NETからSQL Serverのデータベースを使う方法は大きく次の2種類に分類できる。

　　a. ネットワーク（パイプ、共有メモリ）を利用して接続したSQL Serverのサービスからデータベースを利用する
　　b. ASP.NET Webアプリケーションのユーザープロセスからデータベースを利用する

　ここでは両方の利用方法を説明する。

　プログラム上、この2つの相違は、SQL Serverへの接続文字列の違いとなる。

　aを選択した場合、接続文字列は以下となる。なお、ここではSQL ServerへのログインはWindows統合認証を利用することを前提する。

"Data Source=.\SQLEXPRESS;Integrated Security=SSPI;DataBase=データベース名

SQL Serverのサービスからデータベースを利用する場合の接続文字列

　bを選択した場合、接続文字列は以下となる*5。

"Data Source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|データベース名.mdf;User Instance=true"

ユーザープロセスからデータベースを利用する場合の接続文字列

*5　データベースファイルをASP.NETの既定ディレクトリ以外に配置する場合はAttachDBFilenameパラメーターの記述を変える必要がある。

　見ての通り、aと異なりbでは接続先DBのファイルを指定し、かつユーザーインスタンス（プロセスと同義と考えてよい）を利用することを示す。

　従って、さらに別の言い方をすれば、2種類の違いは以下である。

　a. SQL Serverが管理するデータベースを利用する
　　− C:\Program Files\Microsoft SQL Server\MSSQL＜バージョン＞.SQLEXPRESS\MSSQL\DATAディレクトリの下に格納されたデータベースファイルを利用する。なお、ディレクトリ名および「＜バージョン＞」の箇所はインストールしたSQL Server Expressのバージョンやインストール先によって異なる。同時に複数のアプリケーションから利用できる
　b. 固有のデータベースを利用する

　　− ここでの利用方法では、ASP.NET Webアプリを配置するディレクトリの子ディレクトリApp_Dataに格納したデータベースファイルを利用する。この子ディレクトリを持つWebアプリケーションからのみ利用できる

　例えば、運用上の必要から、Webアプリケーションを動かしている間に、別に用意したプログラムからメンテナンスを実行したりするのであれば、aを選択すべきである。そうでないのであれば、Webアプリケーションのディレクトリ上に必要なものを全て完結させられるbの方がアクセス管理上、都合がよいだろう。

　ユーザーのアクセス管理という観点からは以下の違いとなる。

　a. ユーザーの権利をSQL Serverが管理する
　　− データベースファイルそのものは、SQL Serverの管理下にあるため、SQL Serverにログインしたユーザーによってアクセス権限が決定される
　　− ASP.NETは特殊なユーザーなため、アクセス権限をSQL Serverに対して設定する必要がある
　b. ユーザーの権利をファイルシステムが管理する
　　− ユーザープロセスが、指定したファイルに対するアクセス権を持つ必要がある

　あるいは配布という切り口では次のように言うこともできる。

　a. SQL Server用のツール、例えばSQL Server Management Studioを使ってデータのエクスポート／インポートでデータを配布する
　b. データベースファイルをコピーして配布する

　以上のことを念頭に置いて、以下ではデータベースの準備をしていこう。