Предисловие
Я столкнулся с такой проблемой в своей работе за день до вчерашнего дня. Я инкапсулировал POJO в параметры интерфейса. Это очень распространено. Когда есть много параметров, инерционное мышление состоит в том, чтобы инкапсулировать POJO. Тогда есть много аннотаций, которые нужно добавить перед параметрами, такими как: @requestparam, @requestbody, @pathvariable и т. Д. Мое понимание такова. Прежде всего, я заявлю, что никогда не читал исходный код, но я просто понимаю его на основе опыта. @RequestParam пытается использовать для получения запросов. Параметры находятся на URL в заголовке HTTP. Какое конкретное место? Следующее существует в форме ключа = значение. @Requestbody применяется к параметрам запроса публикации параметров запроса в корпусе HTTP. @pathvariable, в частности, является методом написания спокойствия. Поместите параметры на URL без вопросов, чтобы отличить, является ли это параметром или URL. Может, я не очень точно сказать это. Но я обычно использую это таким образом. В то же время существует также общий способ написать параметры, которые должны не добавлять аннотацию перед параметрами. Например, если параметры являются основными типами, не добавляйте @RequestParam, и если параметры - это бобы, не добавляйте запроса, их также может быть проанализировано с помощью SpringMVC. После того, как мой интерфейс был замечен руководителем команды, он попросил меня удалить @requestbody, потому что, добавив это в бэкэнд, запрос Ajax на передней части должен отобразить тип контента: «Приложение/JSON», который будет проанализирован SpringMVC, который, похоже, сделал что-то ненужное. Хотя я удалил его в соответствии с его требованиями, я думаю, что должен выяснить, что происходит, в чем разница между добавлением или не добавлением, каким влиянием это оказывает на производительность или лучшие применимые сценарии для каждого. В дополнение к Байду, я также должен спросить мастеров.
Процесс анализа параметров интерфейса Spring MVC
Во -первых, я медленно изучал исходный код путем отладки. Без добавления аннотаций:
Во время процесса разработки разрешения и производства, как правило, не добавляются. Это должно быть добавлено соответственно, потому что он может уменьшить диапазон поиска интерфейса. Это простая демонстрация, мне просто нужно, чтобы он проверил процесс запросов на получение SpringMVC.
Во -первых, после начала Tomcat пути запроса во всех классах контроллера @Requestmapping, а бобы контроллера загружаются в пружинный контейнер. После того, как запрос страницы появится, есть сервлет для диспетчеров. После того, как запрос приходит к сервлету, все знают, что существуют два метода инициализации сервлета. Одним из них является немедленно загружать, а другой - загрузить задержку. Тем не менее, независимо от того, метод инициации называется только один раз, а затем метод обслуживания будет вызывать непосредственно каждый раз. Когда Tomcat закрыт, метод уничтожения сервлета заканчивается. Следовательно, инкапсуляция SpringMVC сервлета должна наследовать метод обслуживания, а диспетчерервлет также является методом Dodispatch. В этом методе путь запроса получается с использованием объекта httpservletrequest, который является /notjson, а затем сравните его со всеми URL -адресами в контейнере, чтобы наконец получить интерфейс в контроллере. После поиска интерфейса вы, естественно, узнаете параметры интерфейса. Вот я отображаю. Для удобства и простоты на дисплее есть только два параметра, которые являются двумя в запросе AJAX ниже.
Springmvc получит свойства в Pojo посредством размышлений. В этом процессе SpringMVC сначала объявит массив. Размер этого массива является количеством параметров. У меня есть только один здесь. На самом деле, я считаю, что многие люди столкнутся с той же проблемой, что и я. Когда параметры бобов и основных типов существуют одновременно, как Springmvc это разыгрывает? Я сталкивался с этим несколько раз. Не глядя на исходный код, основные типы также инкапсулируются в фасоль, а фронт-энд также будет писать атрибуты в объекте. Конечно, я считаю, что это то, что не все могут принять. Мы все надеемся выяснить, как он это анализирует, чтобы мы могли возиться с ним в то время. Ниже приведен процесс отражения. Размышляя о своем поожо, я получаю свойства и методы внутри. После анализа параметров назначьте значения параметрам. Это, пожалуй, самое важное место. Как именно назначается?
Из этого метода отладка я узнал, что это имя - дисплей, который является строчным именем имени класса Pojo. Я не знаю, почему Springmvc сделал эту обработку (см. Позже). Атрибут является объектом с возрастом и именем. Но в это время это все ноль. WebDataBinding - это специальный дата, используемый для привязки данных из параметров веб -запроса к Javabean -объектам. В соответствии с методом BindRequestParameters вы найдете очень знакомое место, когда следуют за ним. Имя параметра получается с использованием String[] values = request.getParameterValues(paramName); Это метод получения параметра сервлета, поэтому вы можете знать имя атрибута и значение атрибута запрошенного параметра.
Далее, возможно, что это имя параметра заменяется именем атрибута бобов, а возраст имени параметра заменяется возрастом имени атрибута. Следуйте этому месту, Oragina - это пара значений имен свойств, полученная вышеупомянутым серплетом, преобразуя эту карту в PropertyValue здесь. (PropertyValue - это объект, который содержит информацию и значения свойства одного фасоля. Использование здесь объекта вместо того, чтобы просто хранение всех свойств в карте, напечатанной именем свойства, обеспечивает большую гибкость и способность обрабатывать индексированные свойства и т . Д. Объекты PropertyValue.
При преобразовании вы будете игнорировать неизвестные атрибуты
На рисунке выше показан конкретный метод преобразования, который относительно длинный. Следующее предложение напрямую присваивает значение бобам. От этого процесса. Пока свойства объекта JSON Front-Tend такие же, как и свойства бобов, AJAX не пишет контент-тип и использует application/x-www-form-urlencoded; charset=UTF-8 , вы можете напрямую присваивать значения.
Суммировать
Вышеуказанное - все содержание этой статьи. Я надеюсь, что содержание этой статьи имеет определенную справочную ценность для каждого обучения или работы. Если у вас есть какие -либо вопросы, вы можете оставить сообщение для общения. Спасибо за поддержку Wulin.com.