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

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



DBから取得したデータをブラウザに送信
2-(2)の処理について検証

　Webアプリケーションでは、画面はHTMLとしてブラウザに送信します。このため、以下の必要があります。

（e）データをテキスト化
（f）表示形式に応じて、HTMLの適切な個所に埋め込む

　独自開発ではどのようなやり方があるか、WDCではどのようにしているか、まとめてみ
ます。

独自開発の場合

（e）のデータのテキスト化はそれほど手間のかかるものではありませんが、（f）はやや面倒な場合があります。図3-1の画面で見てみますと、上側の表の過ごし方は、プルダウンメニューに表示しています。

過ごし方が「座位12時間..」の場合は、

<select name="sugoshikata" size="1" >
  <option value ="01" selected >座位12時間，立位3時間，歩行1時間</option>
  <option value ="02">座位7時間，立位7時間，歩行2時間</option>
</select>

過ごし方が「座位7時間..」の場合は、

<select name="sugoshikata" size="1" >
  <option value ="01">座位12時間，立位3時間，歩行1時間</option>
  <option value ="02" selected >座位7時間，立位7時間，歩行2時間</option>
</select>

のように、値に対応したoptionタグに「selected」を付ける必要があります。

また、下側の表の数量は、入力フィールドに値を表示しています。値が「2」の場合は、valueのところに値をセットします。

<input type="text" name="num1" value="2" size="4" maxlength="20" >

これらの処理をすべてJSPで行う場合は、コーディングが複雑になることもあり、コーディングミスをしやすい、メンテナンスが難しい、といった問題が出やすくなりますので、注意が必要です。

このような問題を避けるために、JSPですべてを行うのではなく、データ格納クラスからデータを受け取ってHTMLを生成しJSPに渡すような、HTML生成クラスを用意する方法もあります。

WDCを使う場合

WDCではWeb入出力用のクラスが用意されていて、データはそのクラスのオブジェクトを通すことでHTMLに変換され、JSPから呼ばれます（第2回 図2参照）。

コーディング内容は次のようになります。

・データ格納オブジェクトに対応する、Web入出力用オブジェクトを用意
図3の上側の表データに関しては、CalorieNoteForm.javaの68行目で、データ格納オブジェクトとWeb入出力用オブジェクトを結び付けています。

・Web入出力用オブジェクトで、各データの表示形式を設定
図3の上側の表の過ごし方に関しては、CalorieNoteForm.javaの103〜106行目で、プルダウンメニューとして設定しています。下側の表の数量については、115行目で、入力フィールドとして設定しています。

・JSPでWeb入出力オブジェクトを通して値を取得
過ごし方については、CalorieNote.jspの65行目で値を取得しています。この1行で、プルダウンメニューが、既存データと一致する選択肢が選ばれた状態で表示されるようになります。

数量の場合は、CalorieNote.jsp の 110行目の1行で、メニュー、カロリー、数量、摂取カロリーをまとめた、表形式のHTMLを取得しています。表示する列の順番は、14〜19行目で、数量の入力フィールドの表示幅は23行目で設定しています。

このような仕組みを用意することによって、表示列の順番を変えたり、表示形式を変えたり、前回の仕様変更のように項目を増やしたりしても、HTMLの細かい制御をする必要もなく、アプリケーションロジックに、より集中できることになります。

　次に、ユーザーが画面の値を変更して[データ登録]をクリックした後の、Webアプリケーションの処理を見てみましょう。

ユーザーが変更した値を取得しビジネスロジックを実行
4-(1)の処理について検証

　ブラウザからサーバに送られるデータはテキストデータで、パラメータの名前とその値が対になっています。[データ登録] ボタンがクリックされたということも、パラメータの名前と値で判断する必要があります。従って、アプリケーションのロジックとしてみた場合、パラメータには操作系のパラメータと、データとしてのパラメータの2種類があることになります。これらパラメータの名前と値は、画面を表示する際にHTMLに含まれているものですので、実は1つ前の<画面としてブラウザに送信（2-(2)）>のところで、以下の処理を行う必要があります。

（g）パラメータの名前と値を決めてHTMLにセットする

独自開発の場合
パラメータの名前と値を定義し、JSPに記述します。ただし、図3の下側の表データのように、行数の決まっていない複数行データでパラメータを設定する場合には、名前付けをプログラムで処理する必要があります。

WDCを使う場合

・操作系パラメータ
値を定義し、JSPに記述します。名前に付いては、WDCから送信用の名前を取得するようにします（サンプルでは、CalorieNote.jspの98行目が[データ登録]ボタンになります）。

・データ用パラメータ
名前は、WDC が自動生成してセットします。値についても、既存データがある場合は、WDC によってその値がセットされます。データ用パラメータに関しては、コーディングする必要はありません。

　さて、上記のように設定したパラメータを、Webアプリケーションが受け取るときには、どのような処理が必要でしょうか。

独自開発の場合
・操作系パラメータの値を取得して、ユーザーがどの操作を選んだか判別
リクエストから、パラメータ名を指定して値を取得します。
・選ばれた操作に応じて、データ用パラメータから値を取得
リクエストから、パラメータ名を指定して値を取得しますので、パラメータ名とデータ項目の対応を確認してコーディングすることになります。
・値をチェックし、問題があれば、エラー処理

データ項目ごとに、取得したパラメータの値が適正な値かどうかチェックします。例えば、データタイプに合った値かどうか、アプリケーションロジック的に正しい値かどうか、などです。もしそのデータがDBに登録されるデータであれば、最低限、DBの列定義上問題ないことを確認する必要があります。

データチェックで問題があった場合は、ユーザーが送信した画面と同じ内容のものにエラーメッセージを追加して表示したり、エラー専用の画面を表示するなどして、ユーザーに知らせます。
・チェックが通ったら、新たな値をデータ格納オブジェクトの該当項目に格納
データ項目ごとに、適切なデータタイプに変換する必要があります
・新たな値を使って、ビジネスロジックを実行

WDCを使う場合
・操作系パラメータの値を取得して、ユーザーがどの操作を選んだか判別
WDCのAPIを使って操作系パラメータの値を取得します(サンプルでは CalorieNoteForm.java の、Oracle版で146行目、PostgreSQL版で152行目の1行になります)。
・選ばれた操作に応じて、データ用パラメータから値を取得

データ用パラメータの値は WDC が自動的に取得しますので、コーディングの必要はありません。

・値をチェックし、問題があれば、エラー処理
もともとDBから参照したデータ項目であれば、DBの列定義の情報もデータ格納クラスのオブジェクトに自動で設定されます（ただし、DBにPostgreSQLを使う場合は、NULL不可などの情報が問い合わせ結果に含まれないので、アプリケーション側で設定する必要があります）。パラメータの値がこの設定に合っているかどうかは、WDCのAPIを使ってチェックできます（サンプルではCalorieNoteForm.javaの、Oracle版で173、174行目、PostgreSQL版で179、180行目になります）。これにより、チェック漏れやコーディングミスが原因でDB登録時にエラーが起こる、ということを防ぎやすくなります。このデータチェックで問題があった場合のエラーメッセージの表示もWDCのAPIを使って行えます（サンプルではCalorieNoteForm.javaの、Oracle版で176行目、PostgreSQL版で182行目になります）。
・チェックが通ったら、新たな値をデータ格納オブジェクトの該当項目に格納
WDC APIによる値のチェックで問題がなければ、新たな値はデータ格納オブジェクトに自動的に格納されます。
・新たな値を使って、ビジネスロジックを実行
ビジネスロジックの実行でデータを使う際にも、データ格納オブジェクトによってデータの持ち方やアクセス方法を統一できることで、設計作業の軽減やコーディングミスの減少、メンテナンス性の向上といった面での効果があります。


変更されたデータでDBを更新
4-(2)の処理について検証

　ユーザーによって変更された値、ビジネスロジックの実行によって新しくなった値を、
DBに反映します。

独自開発の場合
・変更された値で、DBを更新
DB参照時と同様、JDBC APIを使ったコーディングで、次の処理を行います。

・DBコネクションの取得
・DBをUpdateするためのStatementの作成
・トランザクションの開始
・SQL文の作成（変更されたデータ項目を調べて、Update文を作成します（変更されたことを判別するための何らかの仕組みが必要です）。複数のUpdate文が必要になる場合もあります）
・Updateの実行（エラーがあった場合はトランザクションを取り消します。Update文が複数の場合は、実行も複数回行います）
・トランザクションの終了
・DBコネクションの解放

　

WDCを使う場合
・変更された値で、DBを更新
　 WDCのAPIを使います。更新SQLの作成、Updateの実行など、ほとんどが自動化されています。

・DBコネクションの取得（WDCのAPIを使います。コネクションプールから取得できます）
・DBをUpdateするためのStatementの作成（自動化されています）
・トランザクションの開始（自動化されています）
・SQL文の作成（自動化されています）
・Updateの実行（Updateの実行およびエラーがあったときのトランザクションの取り消しも自動化されています）
・トランザクションの終了（自動化されています）
・DBコネクションの解放（自動化されています）

注：一連の処理は、サンプルでは、CalorieNoteForm.javaの、Oracle版で234、235行目、PostgreSQL版で240、241行目になります

　以上、「DB参照してデータを画面に表示し、ユーザーが値を変更したら、それを基に計算し、変更された値をDBに反映する」処理についての、独自開発の場合と、WDC を使う場合の簡単な比較でした。どのような違いがあるか、大まかなイメージだけでもつかんでいただけましたでしょうか。

　今回対象とした「軽やかカロリ〜」の以下の画面だけを見ても、メニューの追加や削除、データ削除といった機能がまだ残っています。また、Webアプリケーションとしてはほかにも以下のような機能を実現する必要があります。

　

  • セッション管理
  • 画面遷移
  • ブラウザの戻るボタン対応
  • プロキシサーバやブラウザのキャッシュ対応

　

 2/3

　INDEX

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


Java Solution全記事一覧






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

注目のテーマ

Java Agile 記事ランキング

本日 月間
＠IT