Préface
J'ai rencontré un tel problème dans mon travail la veille. J'ai encapsulé un POJO dans les paramètres d'interface. C'est très courant. Lorsqu'il existe de nombreux paramètres, la pensée inertielle est d'encapsuler un pojo. Ensuite, il y a de nombreuses annotations à ajouter avant les paramètres, tels que: @RequestParam, @Requestbody, @Pathvariable, etc. Ma compréhension est comme ça. Tout d'abord, je dirai que je n'ai jamais lu le code source, mais je le comprends simplement en fonction de l'expérience. @RequestParam est essayé d'utiliser pour les demandes de GET. Les paramètres sont sur l'URL dans l'en-tête de HTTP. Quel est l'endroit spécifique? Il existe ce qui suit sous la forme de clé = valeur. @Requestbody s'applique aux paramètres de demande de la demande dans le corps HTTP. @Pathvariable est plus particulièrement la méthode d'écriture de RESTFul. Mettez les paramètres sur l'URL sans points d'interdiction pour distinguer s'il s'agit d'un paramètre ou d'une URL. Peut-être que je ne suis pas très précis de le dire. Mais je l'utilise généralement de cette façon. Dans le même temps, il existe également un moyen courant d'écrire les paramètres, c'est-à-dire de ne pas ajouter d'annotation avant les paramètres. Par exemple, si les paramètres sont des types de base, n'ajoutez pas @ReQuestParam, et si les paramètres sont des beans, n'ajoutez pas de dossier, ils peuvent également être analysés par SpringMVC. Après que mon interface ait été vue par le chef d'équipe, il m'a demandé de supprimer le @Requestbody, car après avoir ajouté cela au backend, la demande AJAX sur le front-end doit afficher le type de contenu de la déclaration: "Application / JSON" à analyser par SpringMVC, qui semble avoir fait quelque chose d'inutile. Bien que je l'ai supprimé en fonction de ses exigences, je pense que je dois comprendre ce qui se passe, quelle est la différence entre l'ajout ou ne pas ajouter, quel impact il a sur les performances ou les meilleurs scénarios applicables pour chacun. En plus de Baidu, je dois également demander aux maîtres.
Processus d'analyse des paramètres d'interface Spring MVC
Tout d'abord, j'ai lentement étudié le code source par le débogage. Sans ajouter aucune annotation:
Au cours du processus de développement, les consommations et les produits ne sont généralement pas ajoutés. Il doit être ajouté en conséquence, car il peut réduire la plage de recherche de l'interface. Il s'agit d'une simple démo, j'ai juste besoin de lui pour vérifier le processus des demandes de réception de SpringMVC.
Tout d'abord, après le démarrage de Tomcat, les chemins de demande de toutes les classes de contrôleur sont @RequestMapping et le bean de contrôleur est chargé dans le récipient à ressort. Une fois la demande de page, le servlet Dispatcherservlet est trouvé. Une fois la demande à l'arrivée du servlet, tout le monde sait qu'il existe deux méthodes d'initialisation du servlet. L'un est de se charger immédiatement et l'autre est de charger retardé. Cependant, quoi qu'il en soit, la méthode init n'est appelée qu'une seule fois, puis la méthode de service sera appelée directement à chaque fois. Lorsque Tomcat est fermé, la méthode de destruction du servlet se termine. Par conséquent, l'encapsulation de SpringMVC du servlet doit hériter de la méthode de service, et le Dispatcherservlet est également la méthode Dodispatch. Dans cette méthode, le chemin de demande est obtenu à l'aide de l'objet HttpServleRequest, qui est / notjson, puis le comparez avec toutes les URL du conteneur pour enfin obtenir l'interface dans le contrôleur. Après avoir trouvé l'interface, vous connaissez naturellement les paramètres de l'interface. Ici je suis affiché. Pour plus de commodité et de simplicité, il n'y a que deux paramètres d'affichage, qui sont les deux dans la demande AJAX ci-dessous.
SpringMVC obtiendra les propriétés dans POJO par réflexion. Dans ce processus, SpringMVC déclare d'abord un tableau. La taille de ce tableau est le nombre de paramètres. Je n'en ai qu'un ici. En fait, je crois que beaucoup de gens rencontreront le même problème que moi. Lorsque les paramètres du bean et des types de base existent en même temps, comment SpringMVC analysera-t-il cela? J'ai rencontré cela plusieurs fois. Sans regarder le code source, les types de base sont également encapsulés dans le bean et le frontal écrira également les attributs d'un objet. Bien sûr, je crois que c'est quelque chose que tout le monde ne peut pas accepter. Nous espérons tous comprendre comment il l'analyse, afin que nous puissions le jouer à ce moment-là. Ce qui suit est le processus de réflexion. Après avoir reflété mon pojo, j'obtiens les propriétés et les méthodes à l'intérieur. Après analyser les paramètres, attribuez des valeurs aux paramètres. C'est peut-être l'endroit le plus important. Comment est affecté exactement?
À partir de cette méthode débogue, j'ai appris que le nom est Affichage, qui est la minuscule du nom de la classe Pojo. Je ne sais pas pourquoi SpringMVC a fait ce traitement (voir plus tard). L'attribut est un objet avec l'âge et le nom. Mais tout est nul à ce moment. WebDatabinding est une databinder spéciale utilisée pour la liaison des données à partir des paramètres de demande Web aux objets Javabean. Suite à la méthode BindRequestParameters, vous trouverez un endroit très familier lorsque vous le suivez est le chiffre suivant. Le nom du paramètre est obtenu en utilisant String[] values = request.getParameterValues(paramName); Il s'agit de la méthode d'obtention du paramètre du servlet, vous pouvez donc connaître le nom d'attribut et la valeur d'attribut du paramètre demandé.
Ensuite, il est concevable que ce nom de paramètre soit remplacé par le nom d'attribut du bean, et l'âge du nom du paramètre est remplacé par l'âge du nom d'attribut. Suivez cet endroit, l'Oragina est la paire de valeurs de nom de propriété obtenue par le serclet ci-dessus, convertissant cette carte en propriété VALUe ici. (PropertyValue est un objet qui contient les informations et les valeurs d'une propriété de bean unique. L'utilisation d'un objet ici au lieu de simplement stocker toutes les propriétés dans une carte tapée par le nom de la propriété permet une plus grande flexibilité et la possibilité de gérer les propriétés indexées, etc. De manière optimisée. Notez que la valeur n'a pas besoin d'être le type requis ultime: la mise en œuvre du beanwraph devrait s'implémenter. PropertyValue Objets.
Lors de la conversion, vous ignorerez les attributs inconnus
L'image ci-dessus montre la méthode de conversion spécifique, qui est relativement longue. La phrase suivante attribue directement la valeur au haricot. De ce processus. Tant que les propriétés de l'objet JSON frontal sont les mêmes que les propriétés Bean de l'arrière-end, Ajax n'écrit pas de type de contenu et utilise l' application/x-www-form-urlencoded; charset=UTF-8 , vous pouvez attribuer directement des valeurs.
Résumer
Ce qui précède est l'intégralité du contenu de cet article. J'espère que le contenu de cet article a une certaine valeur de référence pour l'étude ou le travail de chacun. Si vous avez des questions, vous pouvez laisser un message pour communiquer. Merci pour votre soutien à wulin.com.