2
votes

Pourquoi avons-nous besoin de jackson databind?

Je suis nouveau dans JAVA EE. Ma question est: pourquoi avons-nous besoin de jackson databind? Parce que nous pouvons recevoir les Request Params par @ModelAttribute et les requêtes via http PUT ou POST par @RequestBody . Je ne trouve pas de raison pour laquelle nous avons besoin de jackson databind pour convertir json / xml en POJO ou vice versa.

Merci.


3 commentaires

Comme Jackson ou pas, il s'agit de la bibliothèque de sérialisation de facto pour spring, qui est elle-même la bibliothèque d'injection de dépendances de facto, et spring boot est la plate-forme d'application goto. Utiliser quoi que ce soit d'autre est un travail difficile. Apprenez à aimer la bombe.


Si vous recevez des paramètres de demande à partir d'une publication de formulaire, vous ne recevez pas JSON et vous n'avez pas besoin de Jackson. Vous n’avez jamais besoin de Jackson Databind, cependant si vous écrivez du code client (par exemple JavaScript dans un navigateur utilisant Ajax) qui envoie JSON à votre serveur, utiliser Databind pour analyser le JSON dans un POJO le rend plus facile . Vous avez besoin d'une sorte d'analyseur JSON, car écrire le vôtre serait stupide, étant donné que vous avez accès à de nombreux logiciels gratuits, mais ce n'est pas nécessairement Jackson non plus, vous pouvez choisir une autre bibliothèque JSON.


Jackson est ce qui fait fonctionner @RequestBody .


3 Réponses :


1
votes

Pourquoi avons-nous besoin de jackson databind?

Parce que représenter des données structurées est beaucoup plus facile avec XML (ou JSON) qu'avec de simples paires nom-valeur.

Parce qu'il est plus pratique d'envoyer et de recevoir du JSON du côté client lorsque vous faites AJAX.

Parce qu'une fois que vous devez gérer l'envoi et la réception de JSON ou XML dans l'application Java côté serveur, il est plus pratique de traiter les données structurées en tant que POJO.

Aucun des points ci-dessus ne signifie que vous devez utiliser une liaison. Il existe d'autres moyens de traiter chacun de ces éléments. Mais de nombreux développeurs Java pensent que les liaisons de données sont la meilleure solution: plus efficace en termes de temps de développement et plus fiable. Surtout si vous implémentez des services avec des API complexes. C'est pourquoi ils sont populaires.


Et comme le soulignent d'autres réponses / commentaires, si vous utilisez @RequestBody , alors c'est en utilisant une bibliothèque de liaison sous le capot pour vous donner les POJO. Dans le cas de Spring, c'est Jackson qui est utilisé.


0 commentaires

1
votes

Par défaut, lorsqu'un point de terminaison attend un document JSON en entrée et qu'un argument de méthode de contrôleur donné est annoté avec @RequestBody , Spring utilisera Jackson databind permet de mapper le document JSON entrant sur un objet Java. Vous n'avez pas besoin d'utiliser le ObjectMapper directement, comme Spring le fait pour vous.

Par exemple, considérez la requête HTTP suivante pour créer un commentaire:

@RestController
@RequestMapping("/comments")
public class CommentController {

    @PostMapping(consumes = MediaType.APPLICATION_JSON_VALUE)
    public ResponseEntity<Foo> createComment(@RequestBody Comment comment) {

        // By default, Spring will rely on Jackson databind to map the incoming 
        // JSON document to the comment argument annotated with @RequestBody

        ...
    }
}


0 commentaires

0
votes

Lorsque vous recevez une requête dans certains types de données comme json / xml, la plate-forme Java EE essaiera de désérialiser ces attributs de requête dans un objet modèle de votre projet.

Mais la plate-forme elle-même ne fournit pas d'implémentation de désérialisation prête à l'emploi. Il essaiera donc d'utiliser un fournisseur de dés-sérialiseur dans le chemin de classe comme jackson, jersey, gson, etc.

Comme vous l'avez dit - il est possible d'utiliser @ModelAttribute - mais cette annotation est une meilleure option pour une demande à partir d'une vue de formulaire dans le front-end. Dans le cas de demandes de repos json / xml, @ModelAttribute ne pourra pas convertir correctement les données reçues en classe affaires de votre programme.


0 commentaires