[検証実験]Webシステム開発の効率化を検証する

第3回 フレームワークの効果を検証

石原篤一
テンアートニ
2002/9/20

---

　今回は、前回「仕様変更とフレームワーク効果で」ご紹介したサンプルアプリケーション「軽やかカロリ〜」を通して、フレームワークの効果を確認してみましょう。また、手軽な開発環境構築とフレームワーク導入によって、Webアプリケーション開発がうまく立ち上がってきたら、次にはどのような課題が出てくるのか、進んでいく方向性としてどのようなものがあるのかを考えてみましょう。

　前回紹介したサンプルアプリケーションを作成する際に、1から独自に開発する場合と、WDCを使って開発する場合とではどのような違いがあるのでしょうか。「軽やかカロリ〜」の「ある日の食事内容表の画面」を例に取って見てみましょう。

　「葛飾北斎の2002/01/01のデータがすでに保存されている。そのデータを変更して、登録したい」という状況を想定して、Webアプリケーションが内部でどのような処理を行っているかを見てみます。

1.ユーザーは画面2で2002/01/01のデータを選択
2.Webアプリケーションは以下の動作を行う
（1)データベース（DB）を参照して、葛飾北斎の2002/01/01のデータを取得
（2）画面3として、そのデータをブラウザに送信

（クリックすると拡大します）

3.ユーザーは、過ごし方を「座位12時間..」から「座位7時間..」に、食べた肉野菜いための数を「1」から「20」に変更して、[データ登録]をクリック
4.Webアプリケーションは以下の動作を行う
(1)ユーザーが変更した値を受け取り、その値を使ってカロリー合計と診断結果を計算する（ビジネスロジックに当たる部分）
(2)ユーザーが変更した値、および(1)の計算結果でデータベースを更新する
(3)データベースから、新しくなった2002/01/01のデータを再取得して画面3としてブラウザに送信する

（クリックすると拡大します）

　Webアプリケーションの担当部分2-(1)、2-(2)と4-(1)、4-(2)を、スクラッチからの開発で実現する場合は何が必要になるか、また、フレームワークを使う場合はどう変わるのかについて具体的に見ていきましょう（4-(3)の処理は2-(1)、2-(2)と同じです）。

データベースからのデータの取得 2−（1）の処理について比較

　Webアプリケーションのデータベース・アクセスには次の2つの特徴があります。

（a）ブラウザからのリクエストを受けて、レスポンスを返すまでの間に、DBコネクションの確立から終了までを収める

　今回の例では、2.と4.の両方でデータベース・アクセスがありますが、それぞれの中で、データベース・コネクションの確立から終了までを行います。もし2.でコネクションを確立したままにしておくと、3.のユーザー操作のところでブラウザが閉じられたり、別のサイトを見に行って戻ってこなかったりした場合、コネクションが残ったままになってしまうからです。

（b）コネクションプーリングの機能が必要

　上の(a)の特徴があるとはいえ、リクエストがあるたびにコネクションの確立、終了をしているのでは時間がかかってしまいます。また、Webアプリケーションは不特定多数のユーザーを対象とすることが多いので、リクエストごとにコネクションを確立していては、コネクション数がどんどん多くなっていったときに、パフォーマンスの低下や、場合によってはシステムの安定性にも影響が出る可能性があります。

　この2つの問題を解決するための仕組みがコネクションプーリングです。これは、コネクションを管理するクラスがあらかじめ設定された数のコネクションを確立しておいて、Webアプリケーションからの要求によってそれを貸し出し、Webアプリケーションはデータベース処理が終わったら管理クラスに返す、というものです。

　J2EE完全準拠のアプリケーションサーバは、それ自体がJ2EE標準のコネクションプーリング機能を実装していますが、Webコンテナだけを持つ軽量なサーバでは機能を持っていないことがあります。実際、J2EE完全準拠であるiPlanetApplication Server（iAS）の場合はコネクションプーリング機能を実装していますが、今回使っているiWSは持っていません。手軽に環境構築ができるという点で軽量サーバをお勧めしている手前、この点はハンディありなのですが、実用を考えると、やはり、サーバ側で機能を持っていない場合は、独自に機能を実現する必要があるでしょう。

　さて、データベースからのデータ取得では、（a）、（b）の特徴への対応のほかに、データを保持しておくための入れ物が必要です。このデータ格納クラスでは、以下のことが必要になります。

（c）データごとに適切なデータタイプで格納／取り出しができるようにする
（d）複数のデータの組を格納できるように、Vectorや配列などを使い、各データにアクセスするための方法を用意する

　以上の（a）〜（d）を踏まえて、独自開発の場合に必要なものをまとめてみます。

独自開発で必要なもの
・コネクションプーリングの機能（アプリケーションサーバが備えている場合は必要なし）
・データ格納クラス
・DBデータ参照処理でのJDBC APIコーディングとデータ格納
	DBコネクションの取得 DBにQueryを投げるためのStatementの作成 SQL文の作成 Queryの実行 Queryの実行結果をデータ格納クラスのオブジェクトに格納 　データ行がなくなるまで、ループで行ごとに格納する 　格納時にデータタイプを意識する
・DBコネクションの解放

注：JDBC 2.0 Optional Package APIで規定されているCachedRowSetを使うと、データ格納クラスと、Query実行結果のデータ格納部分が簡単になります。

　さて、上記の必要なものがフレームワークを使う場合にはどう変わるでしょうか。

WDCを使う場合
・コネクションプーリング機能
	WDC独自で実装しています。また、アプリケーションサーバがJ2EE標準の機能を実装している場合は、それを利用することもできます
・データ格納クラス
	WDC独自のデータ格納クラスを持っています（第2回の図2の表データオブジェクトが、それに当たります）
・DBデータ参照処理での、JDBC APIコーディングとデータ格納
	WDC独自の高水準APIを用意しているので、JDBC APIを直接コーディングすることはありません。データ格納処理も自動化されています
・DBコネクションの取得
	WDCのAPIを使います。コネクションプールから取得できます
・DBにQueryを投げるためのStatementの作成
	自動化されています
・SQL文の作成
	WDCのAPIを使って、DBトランザクションを担当するクラス（Queryクラス、第2回の図2を参照）に記述します WHERE 氏名 = :氏名 AND 記録日付 = :記録日付 のような形式でパラメータに値を渡す方法が用意されています。文字列をつなげてSQL文を作るような操作や、PreparedStatementでパラメータ部分の「？」の順番に合わせて値をセットする必要がなくなり、コーディングミスを少なくする、ソースを読みやすくするという点で効果があります（図１の上側の表データを取得するSQL文はCalorieNoteQuery.javaの33行目になります）
・Queryの実行
	WDCのAPIを使います（Formクラス（第2回 図2参照）に記述します。サンプルではCalorieNoteForm.javaの、Oracle版で266行目、PostgreSQL版で272行目の1行になります）
・Queryの実行結果をデータ格納クラスのオブジェクトに格納
	Query実行の段階で自動的に格納されます。カラム数がいくつあるか、それぞれのデータタイプは何か、ということを意識する必要はありません
・DBコネクションの解放
	自動化されています

以上がDBデータの取得に関する、独自開発の場合とWDCを使う場合の比較になります。

　

1/3

INDEX
[検証実験]Webシステム開発の効率化を検証 第3回
	Page1 データベースからのデータの取得
	Page2 DBから取得したデータをブラウザに送信 ユーザーが変更した値を取得しビジネスロジックを実行 変更されたデータでDBを更新
	Page3 次なる課題はセキュリティと可用性

Java Solution全記事一覧

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