Webアプリケーションを構築しています。ユーザーのセッション中に、オブジェクトのようなショッピングカートの状態を保存する必要があります。
いくつかのメモ：
そのステートフルオブジェクトをどこに保存しますか？そして、どのように？
更新：ターゲットとしているプラットフォームをリストすることが提案されました-完全に必要かどうかはわかりません...しかし、フロントエンドはASP.NETMVCで構築されているとしましょう。
Commerce Starter Kit と MVC Storefront (および私が構築したその他のサイト) での私の経験から、今あなたが何を考えていても、「製品」とのユーザー インタラクションに関する情報は、ビジネス担当者にとって最も重要です。取得するメトリックが非常に多く、非常に厄介です。
私が経験したすべてのことを保存します。私にとって最も成功したのは、「NotCheckedOut」ステータスの Order オブジェクトを作成し、それにアイテムを追加して、ユーザーがアイテムを追加することです。これにより、ユーザーは複数のカートを持つことができ、Orders テーブルから tar をマイニングできます。また、ステータスを変更するだけで、注文を処理するのも非常に簡単です。
「as they go」を永続化することで、ユーザーは、何らかの理由でカートを終了できない場合に戻ってカートを終了することもできます。許しはeコマースで大規模です.
Cookie は最悪、セッションは最悪、プロファイルはユーザーの概念に関連付けられ、DB にヒットするため、DB を使用することもできます。
あなたはこれをしたくないと思うかもしれません - しかし、あなたは私を信頼する必要があります. あなたに約束します。
私はあなたが提案していることを検討しましたが、それを試すクライアントプロジェクトはまだありません. 実際に最も近いのは、ここで見つけることができる買い物リストです...
http://www.scottcommonsense.com/toolbox.aspx
食料品チェックリストをクリックしてウィンドウを開きます。ASPX を使用しますが、ページに配置された JS 参照を管理するためだけです。残りは、Web サービスを使用して AJAX 経由で行われます。
以前、anon/auth cookie を自動的に使用するコマース サイト用の ASP.NET 2.0 サイトを構築しました。それぞれが提供する GUID 値を使用して、データベース内のデータに関連付けられるユーザーを識別できます。ユーザーが別のコンピューターに移動できるように、認証 Cookie が必要でした。仕事、自宅など。ASP.NET 2.0 のすべての本で当時人気があった複雑な ShoppingBasket オブジェクトを保持するために Profile フィールドを使用することは避けました。データ構造は時間の経過とともに変化するため、「魔法の」シリアル化の問題に対処したくありませんでした。ソフトウェアの変更と同期された更新/変更スクリプトを使用して、db スキーマの変更を管理することを好みます。
クライアントでユーザーを識別する anon/auth Cookie を使用すると、ASP.NET AJAX クライアント側を使用して、ASP.NET の一部として提供される JS プロキシを使用して認証 Web サービスを呼び出すことができます。少なくともユーザーを認証するには、Membership API を実装する必要があります。プロバイダー実装の残りの部分は、安全に NotImplementedException をスローできます。その後、AJAX (ScriptReference 属性を参照) を介して独自のカスタム ASMX Web サービスを使用し、サーバー側のデータでページを更新できます。ASPX ページを完全に廃止し、必要に応じて静的な HTML/CSS/JS のみを使用できます。
1 つの大きな注意点は、JS でのメモリ リークです。同じページに長時間留まると、メモリ リークの潜在的な問題が増加します。長いセッションをテストし、Firebug などのツールを使用してメモリ リークを探すことで、リスクを最小限に抑えることができます。JS Lint ツールを使用すると、主要な問題を特定するのに役立ちます。
セッションオブジェクトとして保存したいと思います。これは、放棄されたカートに関心がないためです。したがって、データベースに保存する必要がないため、データベースに格納するオーバーヘッドを取り除くことができます (データベースから放棄されたカートを削除するには、何らかのクリーンアップ ルーチンも必要になることは言うまでもありません)。 ）。
ただし、ユーザーがカートを保持できるようにしたい場合は、データベース オプションの方が適しています。このようにして、ログインしているユーザーのカートはセッション間で保存されます (そのため、ユーザーがサイトに戻ってログインすると、カートが復元されます)。
2 つを組み合わせて使用することもできます。サイトにアクセスするユーザーは、デフォルトでセッション ベースのカートを使用します。ユーザーがログインすると、すべてのアイテムがセッション ベースのカートからデータベース ベースのカートに移動され、その後のカート アクティビティはデータベースに直接適用されます。
セッションに使用しているもの（db / memcacheセッション、署名されたCookie）または認証されたユーザーに関連付けられたDB内。
データベースに保存します。
プラットフォームを知らなければ、私は直接的な答えを出すことはできません。ただし、放棄されたカートは気にしないので、ここでは同僚とは異なり、クライアントに保存することをお勧めします。放棄されても構わないのに、データベースに保存する必要はありません。
繰り返しになりますが、格納するオブジェクトのサイズによって異なります。結局のところ、Cookie には制限があります。
編集:ああ、asp.net MVC? プロファイルシステムを使用しないのはなぜですか? わざわざログインさせたくない場合は、匿名プロファイルを有効にすることができます
あるマシン (職場の PC など) で開始し、別のマシン (自宅の PC など) で続行/終了できる必要があると思いますか? もしそうなら、答えは明らかです。
放棄されたカートを気にせず、誰かがクライアント側でデータをいじるための準備をしている場合...特にJSONデータのCookieである場合は、Cookieが適していると思います.
ユーザーバスケットのIDを保持するクライアントで（暗号化された）Cookieを使用します。それが本当に忙しいサイトでない限り、放棄されたバスケットがデータベースをいっぱいにすることはありません. また、このようにすると、ユーザーがブラウザーを閉じて立ち去った場合でも、ユーザーは注文を保持し、セッションのバスケットはこの時点でクリアされます..
最後に、これは、クライアント側の Cookie からのデータの逆シリアル化を処理するコードを書くことについて心配する必要がないことを意味します。私の好みの失敗のポイント）。
状態をサーバーのどこかに保存し、それをユーザーのセッションに関連付けると思います。表面上は Cookie は同じように保存できる場所ですが、セキュリティとデータ サイズを考慮すると、サーバー上にできるだけ多くのデータを保持することが望ましいことになります。
たとえば、公衆端末の設定で、誰かが Cookie の内容を見てリストを表示しても問題ないでしょうか。もしそうなら、クッキーは大丈夫です。そうでない場合は、ユーザーをデータにリンクする ID が必要になります。これを行うと、マシンにすべてを保存するのではなく、そのデータにアクセスするために、ユーザーがサイトに対して認証されていることを確認することもできます。セッション識別子だけでなく、何らかの形式の資格情報も必要になります。
サイズの観点からは、確かに、ブラウザ/ブロードバンド ユーザー向けの 4K Cookie などについてあまり心配する必要はありませんが、ターゲットの 1 つが携帯電話または BlackBerry (3G 以外) の接続を許可することである場合迅速なエクスペリエンスを実現する (そしてデータに対して課金されない) ためには、クライアントに渡されるデータの量を最小限に抑えることが重要になります。
サーバーストレージは、他のいくつかの回答で言及されている柔軟性も提供します。ユーザーはカートをあるマシンに保存し、別のマシンで作業を再開できます。カートを (一時的なセッションではなく) 何らかの形式の資格情報に結び付けて、ユーザーが Cookie をクリアした後もカートを永続化することができます。フォールト トレランスの面でもう少し問題があります。ユーザーのブラウザがクラッシュしても、サイトのデータは安全で健全です。
フォールト トレランスが重要な場合は、データベースのような永続的なストアが必要になります。そうでない場合、アプリケーションのメモリはおそらく問題ありませんが、アプリを再起動するとデータが失われます。ファーム環境にいる場合、ストアは一元的にアクセスできる必要があるため、ここでもデータベースを見ています。
一時的なセッションまたは資格情報によるキーのどちらを選択するかは、ユーザーがデータを保存し、後で戻ってデータを取得できるかどうかによって異なります。一時的なセッションは最終的に「放棄」としてクリーンアップされますが、おそらくそれで問題ありません。ユーザー プロファイルに結び付けることで、ユーザーは自分のデータを保持し、明示的に破棄することができます。いずれにせよ、フォールト トレランスと中央アクセシビリティのために、データベースのようなある種のバッキング ストアを利用します。(または、ソリューションをオーバーエンジニアリングしている可能性がありますか?)
Javascriptを有効にせずにユーザーをサポートすることに関心がある場合は、サーバー側のセッションでURLの書き換えを使用できます。
比較的短いタイムアウト (サーバーの構成によっては約 2 時間) がカートに問題ない場合は、サーバー側のセッションと言えます。DB にアクセスするよりも高速で効率的です。
より長い永続性が必要な場合 (たとえば、一部のユーザーは離れて翌日戻ってくることを好みます)、改ざんが明らかな Cookie に保存します (暗号化またはハッシュを使用します)。