- PR -

ASP.NETでのフォーム値の保存と読込

投稿者投稿内容
どっとねっとふぁん
ぬし
会議室デビュー日: 2005/02/23
投稿数: 935
投稿日時: 2009-04-08 11:12
> というか、遷移する画面間で情報を受け渡すのにSessionを用いるのは
> 適切なやり方かと思います。

私もそう思います。
ただ、元の質問だと、ページの遷移のためにデータを保持しておきたいのか、
次に買い物にきたときのためにデータを持っておきたいのかが微妙な書き方ですね。

>(確かASP.NETでは他画面へPostするのが面倒だった覚えが)

Ver 2.0からだと別ページへのポストバックができるようになってますけど、
ちょっと面倒なのは確かですね。
なので、Kingさんが書いているような画面の流れであれば、私は1ページの中で
表示を切り替えるだけで実装しちゃうことが多いです。

King
ぬし
会議室デビュー日: 2008/06/20
投稿数: 284
投稿日時: 2009-04-08 11:32
タコツボさん
どっとねっとふぁんさん

ありがとうございます。
そういう構成のものばかりを作っていたのであせりました。

> 注文画面などで入力された内容を保存/読込する方法を考えております。

この「読込」の部分が
注文完了するまでの入力チェックや DB 登録するための読込なのか
注文完了後に以前の登録内容を参照するためなのか
が人によって解釈が違っているようですね。

スレッドの話と離れるようで恐縮ですが

> なので、Kingさんが書いているような画面の流れであれば、私は1ページの中で
> 表示を切り替えるだけで実装しちゃうことが多いです。

一度その方法でやってみたのですが、項目数が多かったため
表示状態1での処理、表示状態2での処理、表示状態3での処理・・・
と同一ページ内で分けるのが結構大変でした。(Page_Load 等は共通になりますよね?)
何か上手い方法があるのでしょうか?
ごん太
大ベテラン
会議室デビュー日: 2002/07/30
投稿数: 182
お住まい・勤務地: 森の中
投稿日時: 2009-04-08 22:35
私の場合以下のようにしていました。

ログインIDはセッションで保持

選択した商品をDBカートテーブルへ保存

住所等の情報はDB顧客テーブルからの呼び出し。新規の場合、レコード追加。

確認画面もDBからの呼び出し


基本的には画面移行時はセッションを使うかrequest.querystringで取得しています。
ただし後者はアドレスに表記されるので、気を付けてつかいますが。。

セッションを沢山発行する=サーバー負荷?



[ メッセージ編集済み 編集者: ごん太 編集日時 2009-04-08 22:43 ]
タコツボ
常連さん
会議室デビュー日: 2004/01/20
投稿数: 22
お住まい・勤務地: 京都・大阪
投稿日時: 2009-04-09 10:55
引用:

住所等の情報はDB顧客テーブルからの呼び出し。新規の場合、レコード追加。
確認画面もDBからの呼び出し


以前手がけたECシステムの場合、確認画面まで来てからも
「やっぱ辞〜めた」する客も結構居るということで、
注文確定するまではDB顧客テーブルには登録しない仕様でした。

個人的にも、注文もしていないのに個人情報が登録されてしまう
というのもよろしくないのではないかと思います。

引用:

セッションを沢山発行する=サーバー負荷?


メモリ上に保持した場合には負荷になりそうですが、
DB(SQLServer)に保持すれば、余程無茶なことをしない限り
気にする程のことは無いのではないかと思います。


[ メッセージ編集済み 編集者: タコツボ 編集日時 2009-04-09 10:56 ]
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2009-04-09 22:18
引用:

Kingさんの書き込み (2009-04-08 11:32) より:
> 注文画面などで入力された内容を保存/読込する方法を考えております。

この「読込」の部分が
注文完了するまでの入力チェックや DB 登録するための読込なのか
注文完了後に以前の登録内容を参照するためなのか
が人によって解釈が違っているようですね。


 加えて、セッション情報を“どこに”保存するのかにも、注意したいと思います。
 ASP1.0, 1.1の頃は、インプロセスがデフォルトでした。2.0以降も、それは変わっていなかったと思います。この場合、入力画面から確認画面、実際の登録へ遷移する間にプロセスがリサイクルすると、データはロストします。このロストがどれくらいの頻度で発生するのか、ロストしても大丈夫なのか、そもそもインプロセスで良いのか(よいはずがない)、検証が必要でしょう。
 「入力画面で「次へ」をクリックすると、ログイン前の状態になってしまい、買い物かごもクリアされました。もう一度商品を探しに行くと、すでに品切れでした。」なんて事になったら、ユーザー離れるよ。


 しかし、私が一番危険だと思っているのは、「なるほど でわ、データベースを使用する方法で対応することにします。」のところ。理由を聞かないの?もし、何らかの不都合があって、上司から「なぜデータベースにしまうんだ?!」と質問されたとき、どう答えるのでしょう?

スキルアップ/キャリアアップ(JOB@IT)