ショッピングカートには残りの2つの問題があります。つまり、注文情報とページキャッシュのカスケードストレージです。ここでの情報は、ショッピングカートとショッピングアイテムを指します。つまり、ショッピングカートの情報をデータベースに保存すると、各ショッピングアイテムの情報も保存されます。外国の鍵は関連しています。ページキャッシュの問題とは、ユーザーが注文を確認する時間を指します。クリックすると、注文確認ページに戻ります。注文確認ページが再び発表され、セッションはまだそこにあり、情報は今でも情報です。これは明らかに私たちが望む結果ではなく、後で1つずつ分析します。このセクションでは、主に注文情報のカスケードインベントリとページのキャッシングについて説明します。
1。注文情報のカスケードストレージ
冬眠中の2つの関連テーブルのカスケードストレージを構成する必要があります。ここでは、主に注釈の構成方法を紹介します。注文のポジョはフォーダーであり、ショッピングアイテムのポジョはソーダーであり、フォーダーとソーダーは1対多くの関係です。まず、次のように注釈設定を設定しましょう。
@Entity Public Class Forder Implements java.io.serializable {//無関係なコードを省略...プライベートリスト<Sorder> SOORODERS = new ArrayList <Sorder>（）; @Onetomany（cascade = cascadeType.all、fetch = fetchtype.lazy、mappedby = "forder"）public list <sorder> getSorders（）{return this.sorders; } public void setSorders（list <Sorder> SOORODERS）{this.sorders = soorders; }} @Entity Public Class SorderはJava.io.serializable {//無関係なコードを省略しています... private forder forder; @manytoone（fetch = fetchtype.lazy）@joincolumn（name = "fid"）public forder getForder（）{return this.forder; } public void setForder（forder forder）{this.forder = forder; }}この構成の後、ラインアイテムを保存すると、ショッピングアイテムも保存し、外国の鍵を自動的に関連付けます。しかし、前提は、それらの間の関係を設定する必要があるということです。つまり、ForderのSetSorders（）、SetOrderのSetForder（）、および他の関連する外国の鍵に対応するエンティティのプロパティです。
以前は、ショッピングアイテムをショッピングカートに追加したとき、Forder.Setsorder（Sodder）が実行されました。次に、SoorderにForderを追加する必要があるため、次のように元のコードに追加します。
//これはセクション17のコードです。中央の @service（ "sorderservice"）に文を挿入します。 //ショッピングアイテムが重複しているかどうかをマークするために使用されます// //現在のショッピングアイテムが複製されているかどうかを判断します。重複している場合は、（ソーダー昔：forder.getSorders（））{if（old.getProduct（）。getId（）。equals（sorder.getProduct（）。getId（）））の数量を追加します。 ishave = true;壊す; }} //現在のショッピングアイテムはショッピングカートに存在しません。その時点で、主要なキーソーダーがあります。SetForder（Forder）; forder.getSorders（）。add（sorder）; } forderを返します。 } @Override public Sodder ProductSosorder（製品製品）{SORDER SOORDE = new SORDER（）; soorder.setname（crowt.getName（））; soorder.setNumber（1）; soorder.setprice（product.getPrice（））; Soorder.setProduct（製品）;返品ソダー; }}OK、注文が確認されたときにジャンプするアクションを見てみましょう。
したがって、Forderactionでロジックを完了します。
@controller（ "forderaction"）@scope（ "prototype"）public class forderaction extends baseAction <forder> {@override public forder getModel（）{model =（forder）session.get（ "forder"）;戻りモデル。 } //ショッピングカート（注文）とショッピングアイテム（ラインアイテム）のカスケードストレージ機能を実装しますパブリックストリングSave（）{// //セッションのショッピングアイテムを現在のモデルオブジェクトに渡します// forder forder =（forder）session.get（ "forder"）; // //model.setsorders（forder.getSorders（））; //forder.setAddress（model.getAddress（））; //forder.setName（model.getName（））; //forder.setPhone（model.getPhone（））; //forder.setRemark（model.getRemark（））; //forder.setuser((user)session.get( "user"））; //forder.setStatus(NEWSTATUS（1））; //forder.setPost（model.getPost（））; //forder.setPost（model.getPost（））; //forder.setuser((user)session.get( "user"））; //forder.setStatus(NEWSTATUS（1））; //forder.setPost（model.getPost（））; // //カスケードライブラリ（XMLまたはPOJOの注釈で構成する必要があります）。 //forderservice.save(forder）; model.setuser（（user）session.get（ "user"））; model.setStatus（新しいステータス（1））; forderservice.save（model）; 「銀行」を返します。 }}上記のコードからわかるように、2つの方法があります。1つ目は、getModelメソッド（コメントした部分）を無効にしないことです。この方法は非常に愚かです。 Forderactionはベースアションを継承し、ベースアクションがモデル駆動型インターフェイスを実装するため、合格したデータはモデルにカプセル化されます。モデルは、ベースアクションのプロパティです。次に、セッションのモデル内のすべての情報をフォーダーに渡す必要があります。その後、フォーダーのデータは、ライブラリに入るためにソーダーでカスケードすることができます。ただし、この方法は少し愚かです...したがって、2番目の方法を使用し、GetModelメソッドを書き直し、モデルにForderを直接割り当ててから、モデル、つまり上記の未解決のコードにカスケードアイテムを追加する必要があります。このように、ユーザーがクリックして注文を確認した後、情報がデータベースに入力され、支払いページにジャンプします（次に支払いページを実行する必要があるため、最初にJSPにジャンプすることができます）。
2。ページキャッシングの問題
注文情報のカスケードエントリが解決されましたが、ユーザーがクリックして注文を確認してから戻っている場合、それはまだ元の注文確認ページであり、情報は今でも情報であり、セッションは閉じられていないため、注文情報を再度確認する必要があります。つまり、ユーザーがクリックして注文を確認すると、ページをキャッシュすることはできません。このようにして、ユーザーがクリックして戻ると、ページが期限切れになっていることがわかり、ホームページにジャンプさせます。
フロントエンドのJSPページを設定できるように設定できるため、ブラウザがデータをキャッシュしないようにするため、フロントエンドのconfirm.jspページで次のように設定できます。
しかし、問題はそれほど単純ではありません。これを行うだけでは不可能です。これを行うと、ユーザーは戻ってクリックして、ページの有効期限が切れていることが促されます。ただし、ユーザーがリフレッシュしても不可能な場合、キャッシュには元のデータがロードされます。だから私たちは一つのことを理解しています。セッションはまだ閉じられていないため、セッションのフォーダーの注文情報があります。ユーザーは、リフレッシュした後も間違いなくこのフォーダーを取得し続け、元の注文情報が表示されます。したがって、これをフロントデスクに設定することは、問題をまったく解決できません。また、バックグラウンドで関連する処理を行う必要があります。
問題がわかっているので、これを行うことができます。ユーザーがクリックして注文を確認すると、それを強制的に引き渡し、その後、処理された後、支払いページにジャンプします。私たちはいくつかのトリックを強制的に行うことができます：私たちはセッションで元のフォーダーをクリアします、それは大丈夫ではありませんか？これは実行可能ですが、後で支払いを行う際に注文が依然として注文に関連していることを考えると、セッションの元のフォーダーを別の場所に保存してから、元のフォーダーをクリアできます。したがって、次のように、上記の強制に2行のコードを追加します。
@controller（ "forderaction"）@scope（ "prototype"）public class forderaction extends baseAction <forder> {@override public forder getModel（）{model =（forder）session.get（ "forder"）;戻りモデル。 } //ショッピングカート（注文）とショッピングアイテム（ラインアイテム）のカスケードストレージ機能を実装しますパブリックストリングSave（）{// //セッションのショッピングアイテムを現在のモデルオブジェクトに渡します// forder forder =（forder）session.get（ "forder"）; // //model.setsorders（forder.getSorders（））; //forder.setAddress（model.getAddress（））; //forder.setName（model.getName（））; //forder.setPhone（model.getPhone（））; //forder.setRemark（model.getRemark（））; //forder.setuser((user)session.get( "user"））; //forder.setStatus(NEWSTATUS（1））; //forder.setPost（model.getPost（））; //forder.setPost（model.getPost（））; //forder.setuser((user)session.get( "user"））; //forder.setStatus(NEWSTATUS（1））; //forder.setPost（model.getPost（））; // // cascadedストレージ（XMLまたはpojoの注釈で構成する必要があります）。したがって、SoorderはForderに関連付けられています// // sorderserviceimpl class.save（forder）に追加されます。 //forderservice.save(forder）; model.setuser（（user）session.get（ "user"））; model.setStatus（新しいステータス（1））; forderservice.save（model）; //ショッピングカートはストレージに保管されているため、元のセッションのショッピングカートはセッションをクリアする必要があります。put（ "oldforder"、session.get（ "forder"））; //元のショッピングカート情報を最初に保存します。 "銀行"; }}次に、終了する前に、フロントデスクの注文ページを確認するために次のコードを追加する必要があります。
これでロジックが明確になりました。まず、注文確認ページの場合、Forderにはデータがあるため、空になりません。この判断は無効です。ユーザーがクリックして注文を確認すると、Forderを空のForderオブジェクトに置き換えます。つまり、元のデータがなくなっています（後の支払いのためにセッションの別のキー値ペアに保存します）。このようにして、ユーザーが戻ってクリックして注文確認ページに戻ると、判断が有効になり、ホームページにジャンプします。この時点で、ロジック全体が完了し、ページキャッシュの問題が解決します。
オリジナルアドレス：http：//blog.csdn.net/eson_15/article/details/51433247
上記はこの記事のすべての内容です。みんなの学習に役立つことを願っています。誰もがwulin.comをもっとサポートすることを願っています。