هناك مشكلتان متبقيتان في عربة التسوق ، وهما التخزين المتتالي لمعلومات الطلب وذاكرة التخزين المؤقت للصفحة. تشير المعلومات هنا إلى عربة التسوق وعناصر التسوق. أي عندما نقوم بتخزين معلومات عربة التسوق في قاعدة البيانات ، فإننا نقوم أيضًا بتخزين معلومات كل عنصر تسوق ، وترتبط المفاتيح الأجنبية ، والتي تتضمن مشكلة التخزين المتتالية في السبات ؛ تشير مشكلة ذاكرة التخزين المؤقت للصفحة إلى الوقت الذي يؤكد فيه المستخدم الطلب ، إذا نقر مرة أخرى ، فسيعود إلى صفحة تأكيد الطلب. تأتي صفحة تأكيد الطلبات الآن مرة أخرى ، وما زالت الجلسة موجودة ، ولا تزال المعلومات هي المعلومات الآن. من الواضح أن هذه ليست النتيجة التي نريدها ، وسنقوم بتحليلها واحدًا تلو الآخر. يناقش هذا القسم بشكل رئيسي مخزونات متتالية لمعلومات الطلب وتخزين الصفحات.
1. تخزين معلومات الطلب
يجب تكوين التخزين المتتالي لجدولين ذوي صلة في السبات. هنا نقدم بشكل أساسي طريقة التكوين للشروح. إن Pojo of the Order هو forder ، و pojo من عنصر التسوق هو Sorder ، والفارق والذوي علاقات واحدة إلى حد كبير. أولاً ، دعنا نضع تكوين التعليقات التوضيحية الخاصة بهم ، على النحو التالي:
entity public class forder تنفذ java.io.serializable {// حذف الكود غير ذي صلة ... قائمة خاصة <Sorder> soorders = new ArrayList <Sorder> () ؛ onetomany (cascade = cascadetype.all ، bette = betchtype.lazy ، medby = "forder") قائمة عامة <iorder> getSorders () {return this.sorders ؛ } setSorders public void (قائمة <Sorder> soorders) {this.sorders = soorders ؛ }} entity public class sorder تنفذ java.io.serializable {// حذف الكود غير ذي صلة ... private forder ؛ manyToOne (fetch = betchtype.lazy) joincolumn (name = "fid") public forder getForder () {return this.forder ؛ } public void setForder (forder forder) {this.forder = forder ؛ }} بعد هذا التكوين ، عندما نقوم بحفظ عناصر الخط ، سنوفر أيضًا عناصر التسوق وربط المفاتيح الأجنبية تلقائيًا. لكن الفرضية هي أننا نحتاج إلى ضبط العلاقة بينهما ، أي setSorders () في forder و setForder () في soDord وخصائص في الكيانات المقابلة للمفاتيح الأجنبية الأخرى ذات الصلة.
قبل ذلك ، عندما أضفنا عنصر التسوق إلى عربة التسوق ، تم تنفيذ forder.setsorder (Sorder). الآن نحتاج إلى إضافة Forder إلى soDord ، لذلك نضيفه إلى الكود الأصلي ، على النحو التالي:
// هذا هو الكود في القسم 17. نقوم بإدراج جملة في خدمات الأوسط ("Sorderservice") يمتد الفئة العامة SorderServiceImpl BaseserviceImpl <Sorder> SorderService {Override Public Forder Addsorderorder (forder ، منتج المنتج) // تستخدم لتمييز ما إذا كانت هناك عناصر تسوق مكررة // الحصول على عنصر التسوق الحالي sorder sorder = productTosorder (المنتج) ؛ // احكم على ما إذا كان عنصر التسوق الحالي مكررًا. إذا تم تكرارها ، فأضف الكمية لـ (Sorder Old: forder.getSorders ()) {if (old.getProduct (). getId (). متساوٍ (sorder.getProduct (). ishave = صحيح ؛ استراحة؛ }} // لا يوجد عنصر التسوق الحالي في عربة التسوق ، إذا (! ishave) {// نقوم بإدراج جملة هنا: // قبل إضافة عنصر التسوق إلى عنصر التسوق ، قم أولاً بإنشاء الارتباط بين عنصر التسوق و CARPHING THERPOGNIN في ذلك الوقت ، هناك المفتاح الأساسي sooder.setforder (forder) ؛ forder.getSorders (). add (sorder) ؛ } العودة forder ؛ } Override Public Sorder ProductToSorder (منتج المنتج) {sorder soodric = new Sorder () ؛ soodric.setName (product.getName ()) ؛ soodric.setNumber (1) ؛ soodric.setPrice (product.getPrice ()) ؛ soodric.setProduct (المنتج) ؛ إرجاع Sorder. }}حسنًا ، دعنا نلقي نظرة على أي إجراء للانتقال إليه عندما يؤكد الطلب:
لذلك نذهب لإكمال المنطق في forderaction:
controller ("forderAction") scope ("prototype") فئة forderaction العامة تمتد baseaction <forder> {Override public forder getModel () {model = (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( (Usesser.get ("user ")) ؛ //forder.setStatus (حالة الحالة (1)) ؛ //forder.setpost (model.getPost ()) ؛ //forder.setpost (model.getPost ()) ؛ //forder.setUser( (Usesser.get ("user ")) ؛ //forder.setStatus (حالة الحالة (1)) ؛ //forder.setpost (model.getPost ()) ؛ // // Library Cascaded (يجب تكوينه في شرح XML أو POJO) ، لذلك مطلوب جمعية soDorder // // إضافة إلى sorderserviceimpl class.setForder (forder) ؛ //forderservice.save(forder) ؛ model.setuser ((user) session.get ("user")) ؛ model.setStatus (حالة جديدة (1)) ؛ forderservice.save (نموذج) ؛ إرجاع "البنك" ؛ }} كما يتضح من الكود أعلاه ، هناك طريقتان: الأول لا يتجاوز طريقة getModel (الجزء الذي علقت فيه). هذه الطريقة غبية جدا. نظرًا لأن ForderAction يرث baseactic ، ويقوم BaseAction بتنفيذ واجهة ModelDriven ، سيتم تغليف البيانات التي تم تمريرها في النموذج. النموذج هو خاصية في BASEACTION. ثم نحتاج إلى تمرير جميع المعلومات الموجودة في النموذج إلى Forder في الجلسة ، ثم يمكن أن تكون البيانات الموجودة في Forder متتالية مع Sorder لدخول المكتبة. ومع ذلك ، فإن هذه الطريقة غبية بعض الشيء ... لذلك نستخدم الطريقة الثانية ، وإعادة كتابة طريقة getModel ، وتعيين مباشرة إلى النموذج ، ثم نحتاج فقط إلى إضافة عناصر متتالية في النموذج ، أي الكود غير المعدل أعلاه. وبهذه الطريقة ، بعد أن ينقر المستخدم على تأكيد الطلب ، سيتم إدخال المعلومات في قاعدة البيانات والانتقال إلى صفحة الدفع (يجب إجراء صفحة الدفع بعد ذلك ، حتى تتمكن من القفز إلى JSP أولاً).
2. قضايا التخزين المؤقت للصفحة
الآن تم حل الإدخال المتتالي لمعلومات الطلب ، ولكن إذا نقر المستخدم على تأكيد الطلب ثم العودة ، نجد أنه لا تزال صفحة تأكيد الطلب الأصلية ، ولا تزال المعلومات هي المعلومات الآن ، والجلسة غير مغلقة ، مما يعني أنه يتعين علي تأكيد معلومات الطلب مرة أخرى ، والتي من الواضح أنها غير ملائمة. بمعنى آخر ، عندما ينقر المستخدم على تأكيد الطلب ، لا يمكننا السماح لذاكرة التخزين المؤقت للصفحة. وبهذه الطريقة ، عندما ينقر المستخدم على العودة ، سيظهر أن الصفحة قد انتهت ، ونحن ندعها تقفز إلى الصفحة الرئيسية.
نعلم أنه يمكن تعيين صفحة JSP في الواجهة الأمامية بحيث لا يقوم المتصفح بتخزين بيانات ، حتى نتمكن من تعيينها على النحو التالي على صفحة تأكيد الواجهة الأمامية. jsp:
لكن المشكلة ليست بهذه البساطة. مجرد القيام بذلك غير ممكن. إذا قمت بذلك ، فإن المستخدم ينقر مرة أخرى وسيطلب من انتهاء صلاحية الصفحة. ومع ذلك ، عندما يقوم المستخدم بتحديثه ولم يكن ممكنًا ، سيتم تحميل ذاكرة التخزين المؤقت بالبيانات الأصلية. لذلك نحن نفهم شيئًا واحدًا. نظرًا لأن الجلسة لم يتم إغلاقها بعد ، فهناك معلومات طلب للقوة في الجلسة. سيستمر المستخدمون بالتأكيد في الحصول على هذا forder بعد تحديثه ، وسيتم عرض معلومات الطلب الأصلية. لذلك ، لا يمكن تعيين هذا في مكتب الاستقبال حل المشكلة على الإطلاق. نحتاج أيضًا إلى إجراء المعالجة ذات الصلة في الخلفية.
نظرًا لأننا نعرف المشكلة ، يمكننا القيام بذلك: لأنه عندما ينقر المستخدم على تأكيد الطلب ، فإنه سيسلمه إلى ForderAction ، ثم بعد معالجة forderaction ، فإنه سيقفز إلى صفحة الدفع. يمكننا أن نفعل بعض الحيل في ForDerAction: نحن نمسح forder الأصلي في الجلسة ، أليس كذلك؟ هذا أمر ممكن ، ولكن بالنظر إلى أن الطلب لا يزال ذا صلة بالطلب عند سداد المدفوعات لاحقًا ، يمكننا حفظ forder الأصلي في الجلسة إلى مكان آخر ومسح الأصل الأصلي. لذلك نضيف سطرين من التعليمات البرمجية إلى ForderAction أعلاه ، على النحو التالي:
controller ("forderAction") scope ("prototype") فئة forderaction العامة تمتد baseaction <forder> {Override public forder getModel () {model = (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( (Usesser.get ("user ")) ؛ //forder.setStatus (حالة الحالة (1)) ؛ //forder.setpost (model.getPost ()) ؛ //forder.setpost (model.getPost ()) ؛ //forder.setUser( (Usesser.get ("user ")) ؛ //forder.setStatus (حالة الحالة (1)) ؛ //forder.setpost (model.getPost ()) ؛ // // التخزين المتتالي (يجب تكوينه في شرح XML أو POJO) ، لذلك يرتبط soDore مع forder // // إضافة إلى sorderserviceimpl class.save (forder) ؛ //forderservice.save(forder) ؛ model.setuser ((user) session.get ("user")) ؛ model.setStatus (حالة جديدة (1)) ؛ forderservice.save (نموذج) ؛ . "بنك"؛ }}بعد ذلك ، يتعين علينا إضافة الرمز التالي إلى صفحة تأكيد مكتب الاستقبال:
المنطق الآن واضح. أولاً ، عندما تكون صفحة تأكيد الطلب ، تحتوي Forder على بيانات ، لذلك ليست فارغة. هذا الحكم غير صالح. عندما ينقر المستخدم على تأكيد الطلب ، في ForderAction ، نستبدل forder بكائن forder فارغ ، مما يعني أن البيانات الأصلية قد اختفت (نقوم بحفظها في زوج آخر قيمة مفتاح في الجلسة للدفع لاحقًا). وبهذه الطريقة ، عندما ينقر المستخدم مرة أخرى ويعود إلى صفحة تأكيد الطلب الآن ، فإن الحكم يسري وسوف يقفز إلى الصفحة الرئيسية. في هذه المرحلة ، يكتمل المنطق بأكمله ويتم حل مشكلة ذاكرة التخزين المؤقت للصفحة.
العنوان الأصلي: http://blog.csdn.net/eson_15/article/details/51433247
ما سبق هو كل محتوى هذه المقالة. آمل أن يكون ذلك مفيدًا لتعلم الجميع وآمل أن يدعم الجميع wulin.com أكثر.