(ただいま作成中です。)
方式として決めておいたほうが良いことをざっと決めます。
なお、サンプルフレームワークで実装予定の無いところは、項目だけにしておきます。
1.セッション管理
- HttpSessioを直接開発者に操作させることは、不具合の原因になりやすいため、
管理機構を用意する。
- ブラウザから一定間隔で生存通信(HeartBeat)をサーバに送信し、
システムを開いている間はセッションが切れないようにする。
- ログイン/ログアウト時に自動的にセッションのクリアを行い、
ゴミが残ることを防ぐ。
①画面を行ったり来たりしたときに以前の情報が再表示出来るようにすること。
②ログイン済み、ログインユーザIDなど、認証情報を保存できるようにすること。
(設計中)
2.ファイルアップロード/ダウンロードと永続保存方式
(設計中)
3.PDF/印刷方式
※通常は商用のミドルウェアと連携するため、このサンプルでは作成しない予定。
4.認証/権限方式
(設計中)
5.エラー制御方式
画面設計規約で述べた、エラーハンドリング方法を下記の方法で実装する。
(設計中)
6.ログ出力方式
①フレームワークが自動で出力するログ
「開始」⇒Actionの開始
「終了」⇒Actionの終了
1Action内の、DBアクセス時間の累計とSQL発行回数と
Action全体の処理時間を分けて、終了時のログに出力する。
「アプリケーションエラー」
・データの不整合などが検出された場合に、
個別プログラムでハンドリングするエラー。
エラー時は個別プログラムではエラーのthrowだけ行い、
ログ出力はフレームワークに委ねる。
「システムエラー」
下記のように個別のプログラムでハンドリングできないエラー。
①ハード/OS/ミドルウェアなど基盤の停止・不具合に起因する問題。
②プログラムのバグにより発生する、NullPointerExceptionなどの問題。
・SQLでエラーが発生した場合はSQLの全文をログ出力する。
・Actionでエラーが発生した場合は、リクエストのダンプを出力する。
「処理時間警告」
・Action終了時、SQL終了時に一定以上の時間がかかった場合は、
警告ログを出力する。
「排他制御メッセージ」
・楽観ロックによる排他制御を行った際に、他のユーザーと入力が競合し
再入力を要求するメッセージ。
ログ上は警告とする。
画面上の動きは個別の開発者が実装しなくて良いようにフレームワークで
標準化したいところ。
②個別プログラムで出力するログ
「●名称未定●」
処理停止は必要ないが、管理者が把握し対応が必要なもの。
ただし、24時間即時対応が必要なレベルではなく、夜間バッチで出たら、
管理者を叩き起こすレベルではなく翌朝対応で十分なもの。
「デバッグ」
開発者が任意のものを出してよいが、基本的には単体開発環境だけで出力するもの
とし、本番環境では出力しない。
①出力項目は
- 時刻
- ユーザーID
- ユーザーIPアドレス
- 画面ID
- 画面名
- 操作名(クリックしたボタン名など)
- 種別[開始/終了/エラー/処理時間警告/警告/デバッグ]
- メッセージID
- メッセージ連番(1回のログが複数行になる場合があるので、行ごとに番号を振る)
- メッセージ本文
7.ログインユーザー管理
ログイン中のユーザーを管理者が把握できるようにする。
- セッション管理のところで述べたHeartBeat、ブラウザを閉じるとログインを怠ったユーザー分のセッションもほどなく消えるため、現在のログインユーザが把握可能となる。
8.排他制御方式
データ更新の排他制御について述べる。
- トランザクション分離レベルはRead Committedに設定する。
- Read Committedに設定されするため、1トランザクション内で2度以上同一のレコードを検索することは禁止。ただし、変更の可能性の無いレコードや、変更の可能性があっても問題ないことが保障できる場合は可能とする。
- 1トランザクション内で、同一レコードを読みそのレコードを書き込む場合は、SELECT FOR UPDATEによるロックを実行する。
- SELECT FOR UPDATEを使う場合は、下記のルールに従ってロックする。
①ロック順はテーブル名の昇順とする
②SELECT FOR UPDATE発行時にORDER BY で、主キーの昇順にソートして取得する。
- 画面からの入力されるデータの更新については、楽観ロック方式により、先勝ちによる整合性の確保を実現する。すなわち、検索時にレコードのバージョン番号フィールドをhidden項目に保持し、更新時は、Update文のWHERE句にバージョン番号が一致する事を条件として更新を実施し、該当するレコードが無い場合は、他のユーザーにより更新されているものと判断する。なお、更新時にデータを再取得してはいけない。
9.改ページ方式
改ページの実装方式を規定する。
また、セッションに必要以上のデータを保持しない実装方式について述べる。
- 改ページ対応の一覧形式データ表示の前には、Countで全数を把握後、表示するページの分だけデータを取得する。
10.ブラウザ互換性確保方式
①リセットスタイル
- 下記の3スタイルシートをベースにカスタマイズしたものを用意する。
YUI Liblaryの「reset.css」⇒各ブラウザでデフォルトで設定されているスタイルをリセット
YUI Liblaryの「base.css」⇒独自のスタイルを設定
YUI Liblaryの「fonts.css」⇒各ブラウザのフォントサイズの相違をリセット
{
font-family:
~
}
:first-child+html * {
font-family:
~
}
html * {
font-family:
~
}
- スクロールバーを必ず表示(Fire Fox3でスクロールバーが表示されない問題に対応。
html {
overflow: scroll;
overflow: -moz-scrollbars-vertical;
overflow-x: scroll;
}
②CSSハック
- Google CodeのEI8.jsの使用を検討する。
- ブラウザ個別にスタイルを指定できるハックを利用する。
- ボックスモデルバグなど、主要なバグをあらかじめ把握してスタイルシートを作成する。
- ブラウザ個別の位置の調整にはネガティブマージンを利用する。
メモ
(設計中)
最終更新:2010年03月24日 22:22