1. زيادة المشكلة
في Struts2 ، إذا تم تنفيذ واجهة ModelDriven <domet> ، فيمكن حقن المعلمات التي تم تمريرها في النموذج ، ويمكن استخدام النموذج في الإجراء ، ولكن ماذا يجب أن أفعل إذا كان هناك نموذجان يحتاجان إلى استخدامه في نفس الإجراء؟ على سبيل المثال ، في القسم السابق ، أكملنا وظيفة الدفع عبر الإنترنت ، لكن الدفع لم ينته بعد. نحتاج إلى تلقي ملاحظات المعلومات من أطراف ثالثة. على سبيل المثال ، بعد الدفع الناجح ، نحتاج إلى إرسال رسائل بريد إلكتروني ورسائل نصية إلى الدافع. لذلك نحتاج أيضًا إلى الحصول على المعلمات التي تم تمريرها من الطرف الثالث في الدفع. نظرًا لأن المعلمات التي تم تمريرها من الطرف الثالث تختلف عن تلك التي مررنا بها ، يتعين علينا كتابة نموذج (BackData) لتلقي هذه المعلمات. وبالتالي فإن المشكلة هي أن دفعنا قد كتب على النحو التالي: تمتد دفع الفئة العامة إلى BASEACTION <SrendData> ، أي أن واجهة SendData> تم تنفيذها في BASEACTION. إذن كيف نتلقى نموذجًا آخر في إجراء ما وعلينا التعامل معه بشكل مختلف؟
هناك حل (في الواقع ، لا يمكن أن يطلق عليه الحل ... لأنه لم يتم حله على الإطلاق ...) وهو كتابة نموذج والسماح ليرثه SendData و Backdata ، لكن المشكلة هي أن هذين النموذجين لا علاقة له به على الإطلاق. لماذا نحتاج إلى ورث نفس النموذج؟ لذلك هذا الحل هو في الواقع الهروب من المشكلة أعلاه.
يتم حل هذه المشكلة بشكل جيد في springmvc (لم تبدأ springmvc التعلم حقًا. إذا قلت شيئًا خاطئًا ، فيرجى تصحيحها!) لأن كل طريقة في springMVC تتوافق مع نموذج ، بدلاً من كل إجراء يتوافق مع نموذج ، وهو مناسب. يمكنني فقط كتابة طريقتين في نفس الإجراء ، والطرق المختلفة تتعامل مع نماذج مختلفة.
2. حل للمشكلة
يوفر Struts2 أيضًا حلاً لهذه المشكلة:
Struts2 يخزن العديد من الخرائط في ActionContext ، مثل الطلب ، الجلسة ، التطبيق ، وما إلى ذلك المذكورة سابقًا. هناك أيضًا parametermap ، والذي يخزن جميع معلمات الطلب للطلب. طالما أن عملنا ينفذ واجهة المعلمة ، يمكننا الحصول على هذا parametermap. هذا هو نفس النموذج. إذا قمنا بتطبيق واجهة <DymdRived <DomedDrived ، فيمكننا الحصول على النموذج في الإجراء ، أي تحديد نموذج وتنفيذ طريقة SET.
حسنًا ، من السهل حل المشكلة. معلمات الدفع والمعلمات التي تم إرجاعها مختلفة. وهذا يعني أن المعلمات التي تدخل PayAcition مرتين مختلفة ، أي أن البيانات المثبتة في parametermap مرتين مختلفة. طالما أننا نختار معلمة في الإجراء (يمكن تمييز المعلمة عن طلبتي الطلب المختلفين) كحكم ، سنعرف النموذج الذي يجب استخدامه لتلقي المعلمات (SendData أو BackData). دعنا نعيد كتابة الرمز في الدفع:
Controller ("PayAction")@SCOPE ("النموذج الأولي") تمتد فئة الدفع العامة على BaseAction <Object> Parmeteraware {// لاحظ أن SendData لا يمكن كتابتها في القاعدة الموروثة أعلاه. تحتاج إلى كتابة كائن. في وقت لاحق ، سنحدد أي شخص يجب استخدامه // تحديد خريطة لتلقي طلب خريطة خاصة <String ، String []> ؛ Override public void setParameters (map <string ، string []> parameters) {this.parameters = parameters ؛ } / *في مقالة struts-default.xml ، يتم تنفيذ اعتراض ServletConfig قبل النموذج ، لذلك عندما نضخ النموذج ، تكون معلمة الطلب متوفرة بالفعل ، حتى نتمكن من استخدام المعلمات في طريقة getModel () لتحديد أي طلب يتم استخدامه من قبل المعلمات * /Override getModel () { لا يعود // بهذه الطريقة يمكننا استخدام هذه المعلمة لتحديد ما إذا كان يتم دفعه أو إرجاعه إذا (المعلمات. } آخر {model = new BackData () ؛ } نموذج الإرجاع ؛ } // طريقة إرسال البيانات إلى yibao public string gobank () {// نموذج المرسلة المقابل: SendData SendData SendData = (SendData) ؛ . // منطق التعامل مع البيانات التي تم إرجاعها ... سيتم تنفيذها لاحقًا ، // نقطة معرفة STRUTS2 تتعامل أولاً3. تدفق المعالجة Struts2
دعنا نحلل عملية تنفيذ Struts2 ، والتي ستكون أكثر ملاءمة لفهم المبادئ المذكورة أعلاه. تدفق معالجة الدعامات:
1) بعد الحصول على الطلب ، قم أولاً بإنشاء وكيل الإجراء ، ثم قم بإنشاء الإجراء عند إنشاء الوكيل ؛
2) تنفيذ 18 اعتراضًا ، ثم استدعاء طريقة الإجراء بعد تنفيذ الاعتراض بنجاح ؛
3) بعد تنفيذ طريقة الإجراء ، يتم استدعاء 18 اعتراض. وفقًا لهذه العملية ، نعلم: إنشاء إجراء> ثم تنفيذ المعترض (تنفيذ أولاً servletConfig ، ثم تنفيذ ModelDvenven ، لأن اعتراض ServletConfig مجهزة أمام ModelDdriven). لذلك في الكود أعلاه ، يمكننا استخدام البيانات الموجودة في ParameTerMap في طريقة getModel () لإصدار الأحكام.
استخدم مخطط التوقيت البسيط التالي لتمثيل تدفق المعالجة أعلاه بشكل حدسي:
يوضح هذا تدفق المعالجة لحدس Struts2 ، لذلك من السهل فهم طلبات النماذج المتعددة المعالجة أعلاه. في هذه المرحلة ، تم تحليل جزء من طريقة Struts2 للتعامل مع طلبات النماذج المتعددة. فيما يلي منطق صغير في هذا المشروع.
4. تحسين طريقة تلقي البيانات
المنطق وراء ذلك هو تنفيذ المنطق ، أي معالجة البيانات التي تم إرجاعها. يتضمن المنطق هنا بشكل أساسي: تحديث حالة الطلب (المدفوعة ، الشحن ، إلخ) ، وإرسال رسائل البريد الإلكتروني ، وإرسال الرسائل النصية ، وما إلى ذلك. سنقوم أولاً بإكمال حالة ترتيب التحديث ، وإرسال رسائل البريد الإلكتروني وإرسال رسائل نصية إلى الموضوع ، وسنشكّنها لاحقًا.
أولاً ، قم بتحسين طريقة Backbank ():
public void backbank () {backdata backdata = (backdata) model ؛ System.out.println (نموذج) ؛ Boolean isok = payservice.CheckbackData (backdata) ؛ إذا (isok) {// 1. تحديث حالة الطلب ، يتم إرسال المعلمات وفقًا للموقف في قاعدة البيانات ، المستخدمة لاختبار forderservice.updatestatusbyid (integer.valueof (201605006) ، 2) ؛ // 2. أرسل بريدًا إلكترونيًا وفقًا لعنوان البريد الإلكتروني للمستخدم // 3. أرسل نظام رسائل نص محمول. } آخر {system.out.println ("---- خطأ !!! -----") ؛ }}ثم نكممل طريقة checkbackData (backdata) في Payservice (المنطق هو في الأساس كما في القسم 21):
service ("payservice") الطبقة العامة payserviceimpl تنفذ payservice {// حذف الكود غير ذي صلة/********************************* BackData) {// append string للتحضير للتشفير infobuffer.append (backdata.getp1_merid ()) ؛ infobuffer.append (backdata.getr0_cmd ()) ؛ infobuffer.append (backdata.getr1_code ()) ؛ infobuffer.append (backdata.getr2_trxid ()) ؛ infobuffer.append (backdata.getr3_amt ()) ؛ infobuffer.append (backdata.getr4_cur ()) ؛ infobuffer.append (backdata.getr5_pid ()) ؛ infobuffer.append (backdata.getr6_order ()) ؛ infobuffer.append (backdata.getr7_uid ()) ؛ infobuffer.append (backdata.getr8_mp ()) ؛ infobuffer.append (backdata.getr9_btype ()) ؛ إرجاع infobuffer.toString () ؛ } // تشفير البيانات التي تم إرجاعها وقارنها مع النص المشفر المرسلة. إذا كان موافق ، فهذا يعني أن البيانات لم يتم العبث بها. Boolean CheckbackData (backdata backdata) {String joinparam = this.oinbackDataparam (backdata) ؛ // احصل على سلسلة ciphertext الخاصة بك md5 = digestutil.hmacsign (joinparam.toString () ، المفتاح) ؛ // مقارنة بين النص المشفر مع النص المشفر المرسلة عبر md5.equals (backdata.gethmac ()) ؛ }}أخيرًا ، نكممل طريقة updatestatusbyid في Forderservice:
. تنفذ forderservice {// حذف الرموز الأخرى غير ذات الصلة override public void updatestatusbyid (int id ، int sid) {string hql = "update forder f set f.status.id =: sid where f.id =: id" ؛ getSession (). createquery (HQL) .SetInteger ("SID" ، SID) .SetInteger ("id" ، id) .executeupdate () ؛ }}سيمكن هذا من تحديث حالة الطلب بعد أن يدفع العميل.
الرابط الأصلي: http://blog.csdn.net/eson_15/article/details/51465067
ما سبق هو كل محتوى هذه المقالة. آمل أن يكون ذلك مفيدًا لتعلم الجميع وآمل أن يدعم الجميع wulin.com أكثر.