(RDBのレコード更新/追加のアプリを想定してます。)
データの登録機能のときDBや業務ルールの整合性のチェックを行いますね。(中にはノーチェックの場合もあるかも知れませんが)
登録SQLを発行する前に、UIレベルで可能な範囲のチェックをします。入力可能文字とか範囲とかマスタ存在Checkとか。
RDBの項目制約(x<100とか ="A" = "B" など)を設定している場合は、Insert/Update文を発行して、結果で判断することもありまずが、それは最終判定として有効ですがトラフィック(サーバーとのやり取りが)やトランザクションの維持やなどでサーバーに負荷がかかるのでアプリ内で判断できる範囲は、アプリ内で行うのが良いと考えます。
ボタンを押して、いきなり登録処理を走らせるのはよくないですよね(このケースもありますが)。確認ボタンの存在が望ましいです。そのタイミングの話です。
①1:登録/変更ボタンのClick
2:MessageBox.Show("登録確認","Yes/No")
3:Noの時 : exit
4: エラーチェック
5:Errorがあるとき: MessageBox.Show(" xxxの値がおかしいよ") : Return
6: SQL 発行
7:Errorがあるとき MessageBox.Show(" RDBでError発生") : Return
8: MessageBox.Show("登録しました")
②1:登録/変更ボタンのClick
2:エラーチェック
3:Errorがあるとき: MessageBox.Show(" xxxの値がおかしいよ") : Return
4:MessageBox.Show("登録確認","Yes/No"))
5:Noの時 : exit
6:SQL 発行
7:Errorがあるとき MessageBox.Show(" RDBでError発生") : Return
8:MessageBox.Show("登録しました")
"登録確認" メッセージの出すタイミングがエラーチェックの前後のどちらかなんですが、確認の意味合いが違う気がします。
①は登録ボタンをClickした事の確認で、"今から登録作業に入ります。いいですか?" と聞こえます。
②はエラーが無いので"実登録に入ります"と聞こえます。
私としては、②は実装したことが無かったので、目新しく感じました。
②だと常にエラーチェックが走ります。誤操作で登録キーを押しても走ります。
チェックコストの長短はありますが冗長感がして、①を推奨してます。
開発をばらまいて、仕上がってきた個々のアプリをみると①と②が混在している時があります。明記や統一をしなかった設計側の原因なので、文句はいえません。依頼して統一しました。
統一してないと、エンドユーザーはこの辺りのUIの違いには敏感で、不安感を持たれたりします。
人は自分の経験した姿をデフォル基準とする傾向があるので、明記しないとバラつきがでます。
(*)某パッケージで "会計システムは①" 、"販売管理は②"というのがありました。
プロジェクト単位で統一しても、全社単位では不統一になることもしばしば、作成時期にも左右されるし。PM/SEの感覚の問題もあるし。
少し疑問を感じたものです。
UIの統一は適用が難しいです。確認ダイアログ画面でも、キャンセルボタンとESCキーが連動していないと違和感を覚えますし。(私だけ?)
。自分の作成物も統一してないし....orz.