resumo
O SpringMVC usa o conversor de mensagens para realizar a conversão automática entre mensagens e objetos de solicitação, objetos e mensagens de resposta.
No SpringMVC, você pode usar as duas anotações @RequestBody e @ResponseBody para concluir a conversão de mensagens de solicitação em objetos e objetar mensagens de resposta, respectivamente. O mecanismo de conversão flexível de mensagens subjacente é o recém -introduzido httpmessageConverter, o mecanismo do conversor de mensagens, que é o recém -introduzido httpmessageConverter na primavera 3.x.
A abstração da solicitação #HTTP ainda deve retornar à resposta da solicitação, ou seja, para analisar o corpo da solicitação e retornar a mensagem de resposta. Este é o processo de solicitação HTTP mais básico. Sabemos que, no padrão do servlet, os seguintes métodos na interface javax.servlet.servletRequest podem ser usados:
public servletInputStream getInputStream () lança IoException;
Para obter um servletInputStream. Neste servletInputStream, todo o conteúdo de uma mensagem de solicitação bruta pode ser lido. Da mesma forma, na interface Javax.Servlet.ServletResponse, os seguintes métodos podem ser usados:
public servletOutputStream getOutputStream () lança IoException;
Para obter um servletOutputStream, este servletOutputSteam, herdado do OutputStream em Java, permite que você produz o conteúdo do pacote de resposta HTTP.
Vamos tentar pensar como o designer do Springmvc. Sabemos que os pacotes de solicitação e resposta HTTP são essencialmente uma série de strings. Quando o pacote de solicitação chegar ao mundo Java, ele será encapsulado em um fluxo de entrada do servletInputStream para ler pacotes. A mensagem de resposta é emitida através do fluxo de saída de um servletOutputStream.
Só podemos ler a mensagem de string original do fluxo e, da mesma forma, podemos apenas escrever os caracteres originais no fluxo de saída. No mundo Java, o processamento da lógica de negócios é baseado em objetos específicos de negócios como as dimensões de processamento. Então, quando a mensagem chega ao SpringMVC e sai do SpringMVC, há um problema de impedância entre strings e objetos Java. Esse processo não pode ser convertido manualmente pelo desenvolvedor. Sabemos que no STRUTS2, o OGNL é usado para lidar com esse problema, enquanto no SpringMVC, é o mecanismo httpmessageConverter. Vejamos as duas interfaces primeiro.
#HttpinputMessage Esta classe é uma abstração de uma mensagem de solicitação HTTP no Springmvc. No método read () de httpmessageConverter, existe um parâmetro formal do httpinputMessage, que é a abstração interna do receptor "Mensagem de solicitação" usada pelo conversor de mensagens da Springmvc. O conversor da mensagem extrai mensagens da "mensagem de solicitação" de acordo com as regras e as converte em objetos declarados no parâmetro formal do método.
pacote org.springframework.http; importar java.io.ioException; importar java.io.inputStream; interface pública httpinputMessage estende httpMessage {inputStream getBody () lança IoException;}#HttpOutputMessage Esta classe é uma abstração da mensagem de resposta HTTP no springmvc. No método write () de httpmessageConverter, existe um parâmetro formal do httputputMessage, que é a abstração interna do receptor "Mensagem de resposta" usada pelo conversor de mensagens do Springmvc. O conversor da mensagem grava a "mensagem de resposta" na mensagem de resposta de acordo com certas regras.
pacote org.springframework.http; importar java.io.ioException; importar java.io.outputStream; interface pública httpOutputMessage estende httpMessage {outputStream getBody () lança IoException;}#HttpmessageConverter A abstração de interface de nível mais alto do conversor da mensagem descreve as características gerais de um conversor de mensagens. Podemos entender o processo de pensamento dos designers Spring3.x sobre esse mecanismo dos métodos definidos nesta interface.
package org.springframework.http.converter;import java.io.IOException;import java.util.List;import org.springframework.http.HttpInputMessage;import org.springframework.http.HttpOutputMessage;import org.springframework.http.MediaType;public interface httpmessageConverter <t> {boolean canRread (classe <?> clazz, mediatype mediatype); CANWRITE BOOLEANS (classe <?> clazz, mediatype mediatype); List <PomentyType> getSupportedMediTypes (); T leia (classe <? Extende t> clazz, httpinputMessage inputMessage) lança IoException, httpMessageNotReadableException; Void Write (T t, MediaType contentType, httpOutputMessage OutputMessage) lança IoException, httpMessageNotWritableException;}A definição da interface httpmessageConverter possui métodos emparelhados canilRead (), read () e canwrite (), write (). MediaType é o encapsulamento do atributo de tipo de mídia solicitado. Por exemplo, quando declaramos o seguinte método de processamento.
@RequestMapping (Value = "/String", Method = RequestMethod.Post) public @ResponseBody String readString (@RequestBody String String) {return "Read String '" + String + "'";}Antes de o SpringMVC entrar no método ReadString, ele selecionará a classe de implementação HTTPMESSAGECONVERTER apropriada de acordo com a anotação @RequestBody para analisar os parâmetros de solicitação na variável da string. Especificamente, a classe StringhttpMessageConverter é usada. Seu método CanRead () retorna true e, em seguida, o método read () lerá os parâmetros de solicitação da solicitação e se vinculará à variável string do método readString ().
Quando o SpringMVC executa o método ReadString, como o valor de retorno identifica @ResponseBody, o Springmvc usará o método write () do stringhttpmessageConverter e escreverá o resultado como o valor da string na mensagem de resposta. Obviamente, o método canwrite () retorna true neste momento.
Podemos usar a figura a seguir para descrever brevemente esse processo.
#RequestResponseBodyMethOdProcessor Uma classe descrita no conjunto de processos acima é org.springframework.web.servlet.mvc.method.annotation.requestSponsoBodyMethodProcessor. Esta classe implementa as interfaces HandlermethodargumentResolver e HandlermethodReturValueHandler. O primeiro é uma interface de política que vincula a mensagem de solicitação aos parâmetros formais do método de processamento, e o último é uma interface de política que processa o valor de retorno do método de processamento. Os códigos de origem das duas interfaces são as seguintes:
pacote org.springframework.web.method.support; importar org.springframework.core.methodParameter; importar org.springframework.web.bind.webdatabinder; importação org.springframework.web.bind.support.webtrttrttrttrttratt.weory; org.springframework.web.context.request.nativewebrequest; interface pública handlermethodargumentResolver {boolean supportsParameter (parâmetro MethodParameter); Object resolveargument (parâmetro MethodParameter, ModelAndViewContainer MavContainer, NativeWebRequest WebRequest, WebDatabinderFactory BindFactory) lança a exceção;} pacote org.springframework.web.method.support; importar org.springframework.meth.meth.meth.meth.method.support; importar; org.springframework.web.context.request.nativewebrequest; interface pública handlermethodreturnValueHandler {boolean supportsTurnType (MethodParameter returnType); Void HandleReTurnValue (Objeto ReturnValue, MethodParameter ReturnType, ModelAndViewContainer MavContainer, NativeWebRequest WebRequest) lança exceção;}A classe RequestResponseBodyMethodProcessor também serve como duas funções: análise de parâmetros do método e processamento de valor de retorno. A partir de seu código -fonte, podemos encontrar a implementação do método das duas interfaces acima.
Implementação da interface HandlermethodargumentResolver:
public boolean supportsParameter (parâmetro MethodParameter) {return parameter.hasparameterannotation (requestbody.class);} public objeto resolvearGument (parâmetro MethodParameter, ModelAndViewContainer MavContAiner, NativeWebRequest Webest, WebDatAbrinderCorTtory) CoNTIRAIRS, OBJETIMENTO (OBJETIVOMENTEMENTATIVENTATIVENTATIVENTATIVENER, {OBJETIMENTATIVENTATIVERMAGRAL) parâmetro, parâmetro.getGenericParameterType ()); Nome da sequência = Conventions.getVariableNameForParameter (parâmetro); WebDatabinder Binder = bindFactory.CreateBinder (WebRequest, argumento, nome); if (argumento! = null) {validate (fichário, parâmetro); } MavContainer.addattribute (bindingResult.model_key_prefix + nome, Binder.getBindingResult ()); argumento de retorno;}Implementação da interface handlermethodreturnValueHandler
public boolean supportsreturnType (MethodParameter retornType) {return returnType.getMethodannotation (ResponseBody.class)! = null;} public void HandleRenValue (Object ReturnValue, MethodParameter ReturnType, ModelAndViewContainer) MavContAinner, NativeSweRquherest -S -ReturnTepe, ModelAndView) HttpmediaTypeNotAcceptableException {MavContainer.SetRequestHandled (true); if (returnValue! = NULL) {writeWithMessAgConverters (retornar,, retornarType, webRequest); }}Depois de ler o código acima, todo o contexto de conversão de mensagens HTTPMESSAGECONVERTER já está muito claro. Como a implementação das duas interfaces baseia -se se há @Requestbody e @ResponseBody como condição e, em seguida, httpmessageConverter é chamado, respectivamente, para ler e gravar mensagens.
Se você deseja perguntar como rastrear o requestResponseBodyMethOdProcessor, siga as idéias das postagens anteriores do blog e vá para o Spring-MVC-Showcase para baixar o código-fonte e depurar os exemplos relacionados ao HTTPMESSAGECONVERTER. Enquanto você estiver disposto a trabalhar duro, acredito que você definitivamente ganhará o seu.
#Awatching Zhang Xiaolong Ao falar sobre a essência do WeChat, ele disse: "WeChat é apenas uma plataforma, e as mensagens estão circulando nela". Em nosso processo de análise do código -fonte SpringMVC, podemos entender verdades semelhantes do mecanismo HTTPMESSAGECONVERTER. Aos olhos dos designers SpringMVC, uma mensagem de solicitação e uma mensagem de resposta são abstraídas em uma mensagem de solicitação httpinputMessage e uma mensagem de resposta httpoutputMessage, respectivamente.
Ao processar uma solicitação, o conversor de mensagens apropriado vincula a mensagem de solicitação a um objeto de parâmetro formal no método. Aqui, pode haver vários formulários de mensagem diferentes para o mesmo objeto, como JSON e XML. Da mesma forma, ao responder a uma solicitação, o valor de retorno do método também pode ser retornado a diferentes formulários de mensagem, como JSON e XML.
No SpringMVC, temos diferentes classes de implementação HTTPMESSAGECONVERTER para lidar com vários formulários de mensagem para diferentes formulários de mensagem. No entanto, desde que as "informações válidas" contidas nessas mensagens sejam consistentes, vários conversores de mensagens gerarão o mesmo resultado de conversão. Quanto às diferenças na análise de detalhes entre várias mensagens, elas são bloqueadas em diferentes classes de implementação HTTPMESSAGECONVERTER.
O exposto acima é todo o conteúdo deste artigo. Espero que seja útil para o aprendizado de todos e espero que todos apoiem mais o wulin.com.