ملخص
يستخدم SPRINGMVC محول الرسائل لتحقيق التحويل التلقائي بين رسائل الطلب والكائنات والكائنات ورسائل الاستجابة.
في springMVC ، يمكنك استخدام اثنين من التعليقات التوضيحية @requestbody و @ResponseBody لإكمال تحويل رسائل الطلب إلى الكائنات والكائن إلى رسائل الاستجابة على التوالي. آلية تحويل الرسائل المرنة الأساسية هي HTTPMESSAGECONVERTER التي تم تقديمها حديثًا ، وهي آلية محول الرسائل ، وهي HTTPMESSAGECONVERTER في Spring 3.x.
لا يزال تجريد طلب #HTTP هو العودة إلى استجابة الطلب ، أي لتحليل هيئة الطلب ، ثم إعادة رسالة الاستجابة. هذه هي عملية طلب HTTP الأساسية. نعلم أنه في معيار Servlet ، يمكن استخدام الطرق التالية في واجهة javax.servlet.servletrequest:
servletInputStream getInputStream () يلقي ioException ؛
للحصول على servletinputstream. في هذا servletInputStream ، يمكن قراءة جميع محتويات رسالة الطلب الخام. وبالمثل ، في واجهة javax.servlet.servletresponse ، يمكن استخدام الطرق التالية:
servleTOutputTream getOutputStream () يلقي ioException ؛
للحصول على servleTOutputStream ، يتيح لك هذا servleTOutputSteam ، الموروث من OutputStream في Java ، إخراج محتوى حزمة استجابة HTTP.
دعونا نحاول أن نفكر مثل مصمم SpringMVC. نحن نعلم أن حزم طلب HTTP وحزم الاستجابة هي في الأساس سلسلة من الأوتار. عندما تأتي حزمة الطلب إلى Java World ، سيتم تغليفها في دفق إدخال ServleTInputStream لكي تقرأ الحزم. يتم إخراج رسالة الاستجابة من خلال دفق الإخراج من servleTOutputStream.
يمكننا فقط قراءة رسالة السلسلة الأصلية من الدفق ، وبالمثل ، يمكننا فقط كتابة الأحرف الأصلية في دفق الإخراج. في عالم Java ، تعتمد معالجة منطق الأعمال على الأشياء الخاصة بالأعمال باعتبارها أبعاد المعالجة. ثم ، عندما تصل الرسالة إلى springMVC وتخرج من springMVC ، هناك مشكلة في المعاوقة بين الأوتار وكائنات Java. لا يمكن تحويل هذه العملية يدويًا بواسطة المطور. نحن نعلم أنه في Struts2 ، يتم استخدام ognl للتعامل مع هذه المشكلة ، بينما في SpringMVC ، هي آلية httpmessageconverter. دعونا نلقي نظرة على الواجهتين أولاً.
#httpinputMessage هذه الفئة عبارة عن تجريد لرسالة طلب HTTP داخل SpringMVC. في طريقة read () لـ httpmessageConverter ، هناك معلمة رسمية من httpinputmessage ، وهو التجريد الداخلي لمستقبلات "رسالة الطلب" المستخدمة من قبل محول رسالة springMVC. يقوم محول الرسائل باستخراج الرسائل من "رسالة الطلب" وفقًا للقواعد ويحولها إلى كائنات معلنة في المعلمة الرسمية للأسلوب.
package org.springframework.http ؛ import java.io.ioException ؛ استيراد java.io.inputstream ؛ الواجهة العامة httpinputmessage تمتد httpmessage
#httpoutputmessage هذه الفئة هي تجريد لرسالة استجابة HTTP داخل springMVC. في طريقة الكتابة () من httpmessageConverter ، هناك معلمة رسمية من httpoutputmessage ، وهو التجريد الداخلي لرسالة الاستجابة للمستقبلات المستخدمة من قبل محول رسالة springMVC. يكتب محول الرسالة "رسالة الاستجابة" في رسالة الاستجابة وفقًا لقواعد معينة.
package org.springframework.http ؛ import java.io.ioException ؛ استيراد java.io.outputstream ؛ الواجهة العامة httpoutputmessage تمتد httpmessage
#httpmessageConverter يصف تجريد واجهة أعلى مستوى لمحول الرسائل الخصائص العامة لمحول الرسائل. يمكننا أن نفهم عملية التفكير في SPRING3.X مصممي على هذه الآلية من الأساليب المحددة في هذه الواجهة.
package org.springframework.http.converter ؛ import java.io.ioException ؛ import java.util org.springframework.http.mediatepe ؛ الواجهة العامة httpmessageconverter <t> {boolean canread (class <؟> clazz ، mediaType mediaType) ؛ Boolean Canwrite (Class <؟> clazz ، mediaType MediaType) ؛ قائمة <MediaType> getSupportedMediAtypes () ؛ ر قراءة (فئة <؟ تمتد t> clazz ، httpinputmessage inputMessage) يلقي ioexception ، httpmessagenotreadableable ؛ void write (t t ، mediaType contentType ، httpoutputmessage outputMessage) يلقي iOexception ، httpmessagenotwithablexception ؛}تعريف واجهة httpmessageConverter قد أقترن أساليب canread () ، وقراءة () ، و canwrite () ، وكتابة (). MediaType هو تغليف سمة نوع الوسائط المطلوبة. على سبيل المثال ، عندما نعلن طريقة المعالجة التالية.
requestmapping (value = "/string" ، method = requestMethod.post) publicresponsebody string readString ( @requestbody string) {return "read string '" + string + "'" ؛}قبل أن يدخل SPRINGMVC طريقة ReadString ، سيحدد فئة تنفيذ HTTPMESSAGECONVERTER المناسبة وفقًا لشرح @REQUESTBODY لتحليل معلمات الطلب في متغير السلسلة. على وجه التحديد ، يتم استخدام فئة StringHttpMessageConverter. تُرجع طريقة CanRead () بشكل صحيح ، وبعد ذلك ستقرأ طريقة القراءة () معلمات الطلب من الطلب وترتبط بمتغير السلسلة لطريقة readString ().
عندما تنفذ springMVC طريقة ReadString ، نظرًا لأن قيمة الإرجاع تحدد ResponseBody ، ستستخدم SpringMVC طريقة الكتابة () لـ StringHttpMessageConverter وكتابة النتيجة كقيمة السلسلة إلى رسالة الاستجابة. بالطبع ، تعيد طريقة Canwrite () صحيحًا في هذا الوقت.
يمكننا استخدام الرقم التالي لوصف هذه العملية بإيجاز.
#RequestResponseBodyMethodProcessor فئة موصوفة في مجموعة العملية أعلاه هي org.springframework.web.servlet.mvc.method.annotation.requestResponsebodyMethodProcessor. تنفذ هذه الفئة كلا من واجهات معلية واجهات معلية واجهات معلية. السابق هو واجهة سياسة تربط رسالة الطلب بالمعلمات الرسمية لطريقة المعالجة ، والأخير هو واجهة سياسة تعالج قيمة إرجاع طريقة المعالجة. رموز المصدر للداخلين هي كما يلي:
حزمة org.springframework.web.method.support ؛ استيراد org.springframework.core.methodparameter org.springframework.web.context.request.nativeWebRequest ؛ الواجهة العامة معدات HandlerMethodArgumentResolver {boolean supportparameter (المعلمة methodParameter) ؛ كائن Resolveargument (معلمة MethodParameter ، ModelAndViewContainer Mavcontainer ، NativeWebRequest WebRequest ، WebDatabinderFactory bindfactory) يلقي استثناء ؛} حزمة org.springframework.web.method.support ؛ استيراد org.springframework.core. org.springframework.web.context.request.nativeWebRequest ؛ الواجهة العامة HandlerMethodReturnValueHandler {boolean supporturntype (methodParameter returntype) ؛ void handlereturnvalue (إرجاع الكائن ، returntype methodparameter ، modelandviewcontainer mavcontainer ، nativeWebRequest webrequest) يرمي الاستثناء ؛}تعمل فئة requestResponseBonseDomethodProcessor أيضًا كدورين: تحليل المعلمة الطريقة ومعالجة قيمة الإرجاع. من رمز المصدر الخاص به ، يمكننا العثور على طريقة تنفيذ الواجهتين أعلاه.
تنفيذ واجهة HandlerMethodArgumentResolver:
Public Boolean SupportSparameter (MethodParameter Parameter) {return parameter.hasparameterannotation (requestbody.class) ؛} complic resolveargument (methodparameter parameter ، modelandviewe -mavcontainer ، nativewebrequest webrequest ، webdatabenderfactory) readWithMessageConverters (WebRequest ، parameter ، parameter.getGenericParameterType ()) ؛ اسم السلسلة = Conventions.getVariablenameForparameter (المعلمة) ؛ WebDatabinder Binder = bindFactory.CreateBinder (WebRequest ، الوسيطة ، الاسم) ؛ if (الوسيطة! = null) {التحقق (binder ، المعلمة) ؛ } mavcontainer.addattribute (bindingResult.model_key_prefix + name ، binder.getBindingResult ()) ؛ عودة حجة ؛}تنفيذ واجهة HandlerMethodReturnValueHandler
Public Boolean SupportsReturnType (MethodParameter Returntype) {return Returntype.getMethodannotation (responsebody.class)! = null ؛ httpmediatepenotacceptableException {mavcontainer.setRequestHandled (true) ؛ if (returnValue! = null) {writeWithMessageConverters (returnValue ، returntype ، webrequest) ؛ }}بعد قراءة الكود أعلاه ، فإن سياق تحويل رسالة HTTPMESSAGECONVERTER بالكامل واضح بالفعل. نظرًا لأن تنفيذ الواجهتين يعتمد على ما إذا كان هناك @requestbody و responsebody كشرط ، ثم يتم استدعاء httpmessageconverter على التوالي لقراءة الرسائل وكتابتها.
إذا كنت تريد أن تسأل كيفية تتبع requestResponseBonderMethodProcessor ، فيرجى اتباع أفكار منشورات المدونة السابقة ، ثم انتقل إلى Spring-MVC-Showcase لتنزيل الكود المصدري وتصحيح الأمثلة المتعلقة بـ HTTPMessageConverter. طالما أنك على استعداد للعمل بجد ، أعتقد أنك ستكسب بالتأكيد.
#انقاذ Zhang Xiaolong عند الحديث عن جوهر WeChat ، قال: "WeChat مجرد منصة ، والرسائل تدور فيه". في عملية تحليل رمز مصدر springMVC ، يمكننا أن نفهم حقائق مماثلة من آلية httpmessageConverter. في عيون مصممي springmvc ، يتم استخلاص رسالة طلب ورسالة استجابة في رسالة طلب httpinputmessage ورسالة استجابة httpoutputmessage ، على التوالي.
عند معالجة الطلب ، يربط محول الرسائل المناسب رسالة الطلب بكائن معلمة رسمي في الطريقة. هنا ، قد يكون هناك نماذج رسائل مختلفة متعددة لنفس الكائن ، مثل JSON و XML. وبالمثل ، عند الرد على الطلب ، يمكن أيضًا إرجاع قيمة إرجاع الطريقة إلى نماذج رسائل مختلفة ، مثل JSON و XML.
في SpringMVC ، لدينا فئات تنفيذ HTTPMESSAGECONVERTER مختلفة للتعامل مع نماذج الرسائل المختلفة لنماذج الرسائل المختلفة. ومع ذلك ، طالما أن "المعلومات الصحيحة" الواردة في هذه الرسائل متسقة ، فإن محولات الرسائل المختلفة ستنشئ نفس نتيجة التحويل. أما بالنسبة للاختلافات في تحليل التفاصيل بين الرسائل المختلفة ، يتم حظرها في فئات تنفيذ HTTPMESSAGECONVERTER المختلفة.
ما سبق هو كل محتوى هذه المقالة. آمل أن يكون ذلك مفيدًا لتعلم الجميع وآمل أن يدعم الجميع wulin.com أكثر.