ウェブアプリの設計に問題がないかご指摘いただければと思います。

Question

ウェブアプリの設計に問題がないかご指摘いただければと思います。
たとえば顧客情報入力フォームがありまして、テキストを入力し、確認ボタンを押すと、入力値のバリデーションを実行し、問題があれば入力画面に戻り、エラーメッセージも表示します。問題がなければ入力値をセッションに格納し、実行したいSQLの入ったクラス名、メソッド名、post_keyもセッションに格納し、確認画面を表示します。
確認画面の「送信する」とか「登録する」ボタンを押すと、
セッションに格納されたpost_keyと同一のpost_keyをaction.phpにポストし、
リフレクションを使ってセッションに格納されたクラス名、メソッド名のSQLを実行します（大抵INSERT処理です）。

この処理で意図しない動作が起こるなど、設計上の問題はないでしょうか？
ちなみに、タブブラウザなどで別のタブに別のページを開くと、セッションに格納された入力値や、SQLのクラス名、メソッド名、post_keyは削除されます。
よろしくお願いします。

mizutaki · Accepted Answer

説明が結構難しいですが、
ユーザ情報を登録するなら、その情報はuser_regist.phpみたいな処理に値を渡して
その処理の中でクラスやDB関連のファイルを読み込み、操作を行う。
ユーザ情報を変更するなら、user_edit.phpみたいな処理を呼び出し、上で呼び出したクラスと同類の物を読み込んで、変更処理を行う。
という風にします。
こういう風にした場合、登録した後に確認メールを送る処理を新たに追加する場合は
user_regist.phpの登録処理がうまく行った後にメール送信処理を呼び出す等と
単純な機能追加はあまり考えずに出来ます。

action.phpでやりたい処理が一つのプロセスからなるなら、まだいいのですが、
登録→OKなら登録ID（DBのauto_increment）をメールのテンプレに入れて送信
と、２種類の処理を要求したり
失敗なら一旦登録内容をエラーログに保存してから、エラーページに飛ばすとか
複数の処理を組み合わせて処理を行いたいとなると、
sessionで処理パターンを渡すのは結構大変ですし、
その処理パターンを何らかのファイルに定義しておくなら、
わざわざaction.phpを通さずにその定義ファイルを呼び出しても大して苦労は変わらない。

質問者さんのやりたい事はフレームワーク的で別に悪い方法ではないとは思いますが、
そういうシステムを構築するには少々手間がかかる
そして、想定外の拡張をする際に対応しきれなくなる可能性が出てくる
という危険性があります。

mizutaki · Answer

セッションの削除などをちゃんとすれば、二重投稿なども起こりませんし、
少々気にしすぎかと

ただ、その設計は少々厳しい設計になると思いますよ。
リフレクションをどうとかクラス名やメソッド名という部分を見ると、
情報を取得した時点で、
登録処理を行うクラスを予約して、
実際に実行する時は、
予約した情報を元にクラスや関数を呼び出すようなやり方に見えますが、
そのような手法は手間がかかりますし、
途中でバグが混入しても、追いかけるのが大変になりやすい。
そもそも、情報を取得した時点でクラスやメソッドを予約するメリットが特にないです。

データやページ遷移の情報はセッションで持って、
処理などは全部個々のファイルやプロセスにまかせた方がいい。
クラスやメソッドを持ったまま移動して、その先で処理する方法は、
現時点ではメリットが見えません。

ウェブアプリの設計に問題がないかご指摘いただければと思います。

説明が結構難しいですが、

セッションの削除などをちゃんとすれば、二重投稿なども起こりませんし、

似たような質問が見つかりました

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング