머리말
나는 어제 전날 내 일에서 그런 문제를 겪었다. 인터페이스 매개 변수에서 pojo를 캡슐화했습니다. 이것은 매우 일반적입니다. 많은 매개 변수가 있으면 관성 사고는 pojo를 캡슐화하는 것입니다. 그런 다음 @requestparam, @requestbody, @pathvariable 등과 같은 매개 변수 앞에 추가 할 주석이 많이 있습니다. 내 이해는 다음과 같습니다. 우선, 나는 소스 코드를 읽은 적이 없다고 말하지만 경험에 따라 그것을 이해합니다. @requestparam은 GET 요청에 사용하려고합니다. 매개 변수는 HTTP 헤더의 URL에 있습니다. 특정 장소는 무엇입니까? 다음은 key = value의 형태로 존재합니다. @requestbody는 HTTP 본문의 게시물 요청 매개 변수에 적용됩니다. @PathVariable은 특히 편안한 글쓰기 방법입니다. 모음이없는 URL에 매개 변수를 넣어 매개 변수인지 URL인지를 구별하십시오. 어쩌면 나는 이것을 말하는 것이 그다지 정확하지 않을 것입니다. 그러나 나는 보통 이런 식으로 사용합니다. 동시에 매개 변수를 작성하는 일반적인 방법도 있습니다.이 방법은 매개 변수 전에 주석을 추가하지 않는 것입니다. 예를 들어, 매개 변수가 기본 유형 인 경우 @RequestParam을 추가하지 말고 매개 변수가 Bean이라면 요청 바디를 추가하지 않으면 SpringMVC에 의해 구문 분석 할 수도 있습니다. 팀 리더가 내 인터페이스를 본 후, 그는 @RequestBody를 제거 해달라고 요청했습니다. 왜냐하면 이것을 백엔드에 추가 한 후 프론트 엔드의 AJAX 요청은 SpringMVC에 의해 "Application/JSON"을 표시해야하기 때문에 불필요한 일을 한 것으로 보입니다. 그의 요구 사항에 따라 제거했지만, 무슨 일이 일어나고 있는지, 추가 또는 추가 또는 추가의 차이, 성능에 미치는 영향 또는 각각의 최상의 적용 가능한 시나리오를 파악해야한다고 생각합니다. 바이두 외에도 마스터에게 물어봐야합니다.
스프링 MVC 인터페이스 매개 변수 분석 프로세스
먼저 디버깅을 통해 소스 코드를 천천히 연구했습니다. 주석을 추가하지 않고 :
개발 과정에서 소비와 생산은 일반적으로 추가되지 않습니다. 인터페이스의 검색 범위를 줄일 수 있으므로 그에 따라 추가해야합니다. 이것은 간단한 데모입니다. SpringMVC의 요청을받는 과정을 확인해야합니다.
먼저, Tomcat이 시작된 후 모든 컨트롤러 클래스의 요청 경로는 @requestmapping이고 컨트롤러 Bean은 스프링 컨테이너에로드됩니다. 페이지 요청이 오면 DispatcherServlet 서틀이 발견됩니다. 요청이 서블릿에 오면 서블릿의 두 가지 초기화 방법이 있다는 것을 모두 알고 있습니다. 하나는 즉시로드하고 다른 하나는 지연되는 것을로드하는 것입니다. 그러나 무엇이든간에 INT 메소드는 한 번만 호출되며 서비스 방법은 매번 직접 호출됩니다. Tomcat이 닫히면 서블릿의 파괴 방법이 종료됩니다. 따라서 서블릿의 SpringMVC 캡슐화는 서비스 방법을 상속해야하며 Dispatcherservlet도 Dodispatch 방법입니다. 이 방법에서, 요청 경로는 /notjson 인 httpservletrequest 객체를 사용하여 얻은 다음 컨테이너의 모든 URL과 비교하여 최종적으로 컨트롤러에서 인터페이스를 얻습니다. 인터페이스를 찾은 후에는 인터페이스의 매개 변수를 자연스럽게 알게됩니다. 여기 나는 디스플레이이다. 편의성과 단순성을 위해 디스플레이에는 두 개의 매개 변수 만 있습니다.이 매개 변수는 아래의 AJAX 요청에 있습니다.
SpringMVC는 반사를 통해 Pojo의 특성을 얻습니다. 이 과정에서 SpringMVC는 먼저 배열을 선언합니다. 이 배열의 크기는 매개 변수 수입니다. 나는 여기에 하나만 있습니다. 사실, 나는 많은 사람들이 나와 같은 문제를 겪을 것이라고 믿는다. Bean 및 기본 유형의 매개 변수가 동시에 존재하면 SpringMVC는 어떻게이를 구문 분석합니까? 나는 이것을 여러 번 만났다. 소스 코드를 보지 않고 기본 유형도 콩에 캡슐화되며 프론트 엔드는 객체에 속성을 씁니다. 물론 나는 이것이 모든 사람이 받아 들일 수없는 것이라고 생각합니다. 우리 모두는 그것이 분석하는 방법을 알아 내기를 희망하여 그 당시에는 바이올린을 섭취 할 수 있기를 바랍니다. 다음은 반사 과정입니다. 내 pojo를 반영한 후, 나는 속성과 방법을 내부에 넣습니다. 매개 변수를 구문 분석 한 후 값을 매개 변수에 할당하십시오. 이것은 아마도 가장 중요한 장소 일 것입니다. 정확히 어떻게 할당됩니까?
이 메소드 디버그에서 이름은 Pojo 클래스 이름의 소문자 인 디스플레이라는 것을 알게되었습니다. SpringMVC가 왜이 처리를했는지 모르겠습니다 (나중에 참조). 속성은 나이와 이름이있는 대상입니다. 그러나 지금은 모두 널입니다. WebDatabinding은 웹 요청 매개 변수에서 Javabean 객체로의 데이터 바인딩에 사용되는 특수 데이터베이너입니다. BindRequestParameters 방법을 따르면 다음과 같은 수치를 따를 때 매우 친숙한 장소를 찾을 수 있습니다. 매개 변수 이름은 String[] values = request.getParameterValues(paramName); 이것은 서블릿의 매개 변수를 얻는 방법이므로 요청 된 매개 변수의 속성 이름과 속성 값을 알 수 있습니다.
다음 으로이 매개 변수 이름은 Bean의 속성 이름으로 대체되고 매개 변수 이름 Age는 속성 이름 Age로 대체됩니다. 이 장소를 따르십시오. Oragina는 위의 Serclet에서 얻은 속성 이름 값 쌍 으로이지도를 여기에서 PropertyValue로 변환합니다. (PropertyValue는 단일 Bean 속성의 정보와 값을 보유하는 객체입니다. 속성 이름으로 입력 한 맵에 모든 속성을 저장하는 대신 객체를 사용하여 인덱스 된 속성 등을 처리 할 수있는 능력과 기능을 최적화 할 수 있습니다. 최적화 된 방식으로 값은 최종이 필요한 유형이 될 필요가 없다는 점에 유의해야합니다. 콩 쓰레기 구현이 필요한 대상을 처리해야합니다. 물체.
변환 할 때는 알 수없는 속성을 무시합니다
위의 그림은 특정 변환 방법을 보여 주며, 이는 비교적 길다. 다음 문장은 직접 콩에 값을 할당합니다. 이 과정에서. 프론트 엔드 JSON 객체의 특성이 백엔드의 Bean 특성과 동일하다면 Ajax는 컨텐츠 유형을 작성하지 않으며 기본 application/x-www-form-urlencoded; charset=UTF-8 , 값을 직접 할당 할 수 있습니다.
요약
위는이 기사의 전체 내용입니다. 이 기사의 내용에 모든 사람의 연구 나 작업에 대한 특정 참조 가치가 있기를 바랍니다. 궁금한 점이 있으면 의사 소통을 위해 메시지를 남길 수 있습니다. Wulin.com을 지원 해주셔서 감사합니다.