[検証実験]Webシステム開発の効率化を検証する
第3回 フレームワークの効果を検証
![]() |
DBから取得したデータをブラウザに送信 2-(2)の処理について検証 |
Webアプリケーションでは、画面はHTMLとしてブラウザに送信します。このため、以下の必要があります。
(e)データをテキスト化
(f)表示形式に応じて、HTMLの適切な個所に埋め込む
独自開発ではどのようなやり方があるか、WDCではどのようにしているか、まとめてみ
ます。
独自開発の場合 | |||
(e)のデータのテキスト化はそれほど手間のかかるものではありませんが、(f)はやや面倒な場合があります。図3-1の画面で見てみますと、上側の表の過ごし方は、プルダウンメニューに表示しています。 過ごし方が「座位12時間..」の場合は、
過ごし方が「座位7時間..」の場合は、
のように、値に対応したoptionタグに「selected」を付ける必要があります。 また、下側の表の数量は、入力フィールドに値を表示しています。値が「2」の場合は、valueのところに値をセットします。
これらの処理をすべてJSPで行う場合は、コーディングが複雑になることもあり、コーディングミスをしやすい、メンテナンスが難しい、といった問題が出やすくなりますので、注意が必要です。 このような問題を避けるために、JSPですべてを行うのではなく、データ格納クラスからデータを受け取ってHTMLを生成しJSPに渡すような、HTML生成クラスを用意する方法もあります。 |
WDCを使う場合 |
WDCではWeb入出力用のクラスが用意されていて、データはそのクラスのオブジェクトを通すことでHTMLに変換され、JSPから呼ばれます(第2回 図2参照)。 コーディング内容は次のようになります。 ・データ格納オブジェクトに対応する、Web入出力用オブジェクトを用意 ・Web入出力用オブジェクトで、各データの表示形式を設定 ・JSPでWeb入出力オブジェクトを通して値を取得 数量の場合は、CalorieNote.jsp の 110行目の1行で、メニュー、カロリー、数量、摂取カロリーをまとめた、表形式のHTMLを取得しています。表示する列の順番は、14〜19行目で、数量の入力フィールドの表示幅は23行目で設定しています。 このような仕組みを用意することによって、表示列の順番を変えたり、表示形式を変えたり、前回の仕様変更のように項目を増やしたりしても、HTMLの細かい制御をする必要もなく、アプリケーションロジックに、より集中できることになります。 |
次に、ユーザーが画面の値を変更して[データ登録]をクリックした後の、Webアプリケーションの処理を見てみましょう。
![]() |
ユーザーが変更した値を取得しビジネスロジックを実行 4-(1)の処理について検証 |
ブラウザからサーバに送られるデータはテキストデータで、パラメータの名前とその値が対になっています。[データ登録] ボタンがクリックされたということも、パラメータの名前と値で判断する必要があります。従って、アプリケーションのロジックとしてみた場合、パラメータには操作系のパラメータと、データとしてのパラメータの2種類があることになります。これらパラメータの名前と値は、画面を表示する際にHTMLに含まれているものですので、実は1つ前の<画面としてブラウザに送信(2-(2))>のところで、以下の処理を行う必要があります。
(g)パラメータの名前と値を決めてHTMLにセットする
独自開発の場合 |
パラメータの名前と値を定義し、JSPに記述します。ただし、図3の下側の表データのように、行数の決まっていない複数行データでパラメータを設定する場合には、名前付けをプログラムで処理する必要があります。 |
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を使います。コネクションプールから取得できます) |
注:一連の処理は、サンプルでは、CalorieNoteForm.javaの、Oracle版で234、235行目、PostgreSQL版で240、241行目になります
以上、「DB参照してデータを画面に表示し、ユーザーが値を変更したら、それを基に計算し、変更された値をDBに反映する」処理についての、独自開発の場合と、WDC を使う場合の簡単な比較でした。どのような違いがあるか、大まかなイメージだけでもつかんでいただけましたでしょうか。
今回対象とした「軽やかカロリ〜」の以下の画面だけを見ても、メニューの追加や削除、データ削除といった機能がまだ残っています。また、Webアプリケーションとしてはほかにも以下のような機能を実現する必要があります。
![]() |
- セッション管理
- 画面遷移
- ブラウザの戻るボタン対応
- プロキシサーバやブラウザのキャッシュ対応
2/3 | ![]() |
INDEX |
||
[検証実験]Webシステム開発の効率化を検証 第3回 |
||
Page1 データベースからのデータの取得 |
||
![]() |
Page2 DBから取得したデータをブラウザに送信 ユーザーが変更した値を取得しビジネスロジックを実行 変更されたデータでDBを更新 |
|
Page3 次なる課題はセキュリティと可用性 |
||
![]() |
Java Solution全記事一覧 |
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 (2017/5/9)
ログ基盤の構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介 - Chatwork、LINE、Netflixが進めるリアクティブシステムとは何か (2017/4/27)
「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します - Fluentd+Elasticsearch+Kibanaで作るログ基盤の概要と構築方法 (2017/4/6)
ログ基盤を実現するFluentd+Elasticsearch+Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について - プログラミングとビルド、Androidアプリ開発、Javaの基礎知識 (2017/4/3)
初心者が、Java言語を使ったAndroidのスマホアプリ開発を通じてプログラミングとは何かを学ぶ連載。初回は、プログラミングとビルド、Androidアプリ開発、Javaに関する基礎知識を解説する。
![]() |
|
|
|
![]() |