- - PR -
ASP.NETでのフォーム値の保存と読込
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2009-04-08 11:12
> というか、遷移する画面間で情報を受け渡すのにSessionを用いるのは
> 適切なやり方かと思います。 私もそう思います。 ただ、元の質問だと、ページの遷移のためにデータを保持しておきたいのか、 次に買い物にきたときのためにデータを持っておきたいのかが微妙な書き方ですね。 >(確かASP.NETでは他画面へPostするのが面倒だった覚えが) Ver 2.0からだと別ページへのポストバックができるようになってますけど、 ちょっと面倒なのは確かですね。 なので、Kingさんが書いているような画面の流れであれば、私は1ページの中で 表示を切り替えるだけで実装しちゃうことが多いです。 | ||||||||
|
投稿日時: 2009-04-08 11:32
タコツボさん
どっとねっとふぁんさん ありがとうございます。 そういう構成のものばかりを作っていたのであせりました。 > 注文画面などで入力された内容を保存/読込する方法を考えております。 この「読込」の部分が 注文完了するまでの入力チェックや DB 登録するための読込なのか 注文完了後に以前の登録内容を参照するためなのか が人によって解釈が違っているようですね。 スレッドの話と離れるようで恐縮ですが > なので、Kingさんが書いているような画面の流れであれば、私は1ページの中で > 表示を切り替えるだけで実装しちゃうことが多いです。 一度その方法でやってみたのですが、項目数が多かったため 表示状態1での処理、表示状態2での処理、表示状態3での処理・・・ と同一ページ内で分けるのが結構大変でした。(Page_Load 等は共通になりますよね?) 何か上手い方法があるのでしょうか? | ||||||||
|
投稿日時: 2009-04-08 22:35
私の場合以下のようにしていました。
ログインIDはセッションで保持 選択した商品をDBカートテーブルへ保存 住所等の情報はDB顧客テーブルからの呼び出し。新規の場合、レコード追加。 確認画面もDBからの呼び出し 基本的には画面移行時はセッションを使うかrequest.querystringで取得しています。 ただし後者はアドレスに表記されるので、気を付けてつかいますが。。 セッションを沢山発行する=サーバー負荷? [ メッセージ編集済み 編集者: ごん太 編集日時 2009-04-08 22:43 ] | ||||||||
|
投稿日時: 2009-04-09 10:55
以前手がけたECシステムの場合、確認画面まで来てからも 「やっぱ辞〜めた」する客も結構居るということで、 注文確定するまではDB顧客テーブルには登録しない仕様でした。 個人的にも、注文もしていないのに個人情報が登録されてしまう というのもよろしくないのではないかと思います。
メモリ上に保持した場合には負荷になりそうですが、 DB(SQLServer)に保持すれば、余程無茶なことをしない限り 気にする程のことは無いのではないかと思います。 [ メッセージ編集済み 編集者: タコツボ 編集日時 2009-04-09 10:56 ] | ||||||||
|
投稿日時: 2009-04-09 22:18
加えて、セッション情報を“どこに”保存するのかにも、注意したいと思います。 ASP1.0, 1.1の頃は、インプロセスがデフォルトでした。2.0以降も、それは変わっていなかったと思います。この場合、入力画面から確認画面、実際の登録へ遷移する間にプロセスがリサイクルすると、データはロストします。このロストがどれくらいの頻度で発生するのか、ロストしても大丈夫なのか、そもそもインプロセスで良いのか(よいはずがない)、検証が必要でしょう。 「入力画面で「次へ」をクリックすると、ログイン前の状態になってしまい、買い物かごもクリアされました。もう一度商品を探しに行くと、すでに品切れでした。」なんて事になったら、ユーザー離れるよ。 しかし、私が一番危険だと思っているのは、「なるほど でわ、データベースを使用する方法で対応することにします。」のところ。理由を聞かないの?もし、何らかの不都合があって、上司から「なぜデータベースにしまうんだ?!」と質問されたとき、どう答えるのでしょう? |