Mappage élégant de POJOs à JsonObject de vertx.io?

Je suis actuellement en train de travailler sur un vertx.io application et je voulais utiliser le fournir mongo api pour le stockage de données. J'ai actuellement un assez maladroit abstraction sur le dessus du stock JsonObject classes où tous les get et set méthodes sont remplacés par des choses comme:

this.backingObject.get(KEY_FOR_THIS_PROPERTY);

Cela est bel et bon, pour l'instant, mais il n'est pas particulièrement bien. il semble aussi sale, plus précisément lors de l'utilisation de tableaux imbriqués ou des objets. Par exemple, si je veux être en mesure de remplir les champs uniquement lorsque les données réelles sont connues, je dois vérifier si le tableau existe, et si ce n'est pas le créer et de le stocker dans l'objet. Ensuite, je peux ajouter un élément à la liste. Par exemple:

if (this.backingObject.getJsonArray(KEY_LIST) == null) {
    this.backingObject.put(KEY_LIST, new JsonArray());
}
this.backingObject.getJsonArray(KEY_LIST).add(p.getBackingObject());

J'ai pensé à des solutions possibles, mais n'aime pas particulièrement l'un d'eux. À savoir, je pourrait utilisation Gson ou d'une même bibliothèque avec l'annotation de soutien pour gérer le chargement de l'objet aux fins de manipuler les données dans mon code, et ensuite à l'aide de la serialize et unserialize à la fois fonction de Gson et Vertx convertir entre les formats (vertx to load data -> json string -> gson to parse json into pojos -> make changes -> serialize to json string -> parse with vertx and save) mais c'est vraiment une brute et inefficace de flux de travail. Je pourrais aussi probablement venir avec une sorte de résumé wrapper qui s'étend/implémente l'vertx librairie json, mais elle passe à toutes les fonctionnalités grâce à gson, mais qui semble aussi que beaucoup de travail.

Est-il un bon moyen pour y parvenir plus convivial et plus facile à gérer la sérialisation à l'aide de vertx?

source d'informationauteur grdaneault | 2015-08-17

  1. 16

    Je viens d'envoyer un patch pour Vert.x qui définit deux nouvelles fonctions de confort pour convertir entre JsonObject et Java des instances de l'objet sans l'inefficacité de passer par un intermédiaire chaîne JSON représentation. Ce sera dans la version 3.4.

    //Create a JsonObject from the fields of a Java object.
//Faster than calling `new JsonObject(Json.encode(obj))`.
public static JsonObject mapFrom(Object obj)

//Instantiate a Java object from a JsonObject.
//Faster than calling `Json.decodeValue(Json.encode(jsonObject), type)`.
public <T> T mapTo(Class<T> type)

    En interne, il utilise ObjectMapper#convertValue(...)voir Tim Putnam répondre à des mises en garde de cette approche. Le code est ici.

  2. 8

    Ne sais pas si j'ai bien compris, mais il semble que vous essayez de trouver un moyen simple de convertir des Pojo à JsonObject?

    Donc, nous avons beaucoup de pojo que nous envoyons plus de la EventBus comme JsonObjects

    J'ai trouvé le moyen le plus facile est d'utiliser le vert.x Json classe qui a la charge de méthodes d'aide à la conversion à partir de Json Strings

    JsonObject jsonObject = new JsonObject(Json.encode(myPojo));

    Parfois, vous avez besoin d'ajouter un peu personnalisé (de)sérialiseurs, mais nous nous en tenons toujours avec Jackson - c'est ce que Vert.x est à l'aide de sorte qu'elles fonctionnent hors de la boîte.

    Ce que nous faisons, c'est de proposer une interface comme suit:

    public JsonObjectSerializable {
    public JsonObject toJson();
}

    Et tous nos objets pojo qui doivent être envoyés sur le EventBus ont pour implémenter cette interface.

    Alors notre EventBus l'envoi de code ressemble à quelque chose comme (simplifié):

    public <T extends JsonObjectSerializable> Response<T> dispatch(T eventPayload);

    Aussi, comme nous n'ont généralement pas de test de l'unité Pojo, l'ajout de cette interface encourage les développeurs à l'unité de test de leur conversion.

    Espère que cette aide,

    Sera

  3. 5

    Je crois Jackson ObjectMapper.convertValue(..) fonctions ne se convertissent pas, via la Chaîne, et Vert.x est à l'aide de Jackson pour la gestion des JsonObject de toute façon.

    JsonObject a juste un sous-jacent de la carte représentant les valeurs, accessible via JsonObject.getMap()et une Jackson sérialiseur/deserializer sur le public ObjectMapper instance io.vertx.de base.json.Json.

    Pour basculer entre JsonObject et un modèle de données exprimées dans Pojo serializable avec Jackson, vous pouvez le faire:

    JsonObject myVertxMsg = ...
    MyPojo pojo = Json.mapper.convertValue ( myVertxMsg.getMap(), MyPojo.class );

    Je suppose que c'est plus efficace que de passer par l'intermédiaire d'une Chaîne de caractères (mais c'est juste une supposition), et je déteste l'idée de modifier les données de la classe, juste pour s'adapter à l'environnement, donc ça dépend du contexte - forme vs performance.

    Pour convertir de Pojo à JsonObjectconvertir une carte avec Jackson et ensuite utiliser le constructeur sur JsonObject:

    JsonObject myobj = new JsonObject ( Json.mapper.convertValue ( pojo, Map.class ));

    • Si vous avez imbriquée implicite JsonObjects ou JsonArray objets dans votre définition, ils seront instanciés que les Cartes et les Listes par défaut. JsonObject en interne ré-emballer lorsque vous accédez à des champs en précisant les types (par exemple, avec getJsonArray(..).

    • Parce que JsonObject est libre et vous êtes à la conversion d'un type statique, vous pouvez obtenir des indésirables UnrecognizedPropertyException à traiter. Il peut être utile de créer votre propre ObjectMapper, ajouter le vertx JsonObjectSerializer et JsonArraySerializer, puis modifiez la configuration de costume (comme DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES dans Jackson).

  4. 0

    Essayez ceci:

    io.vertx.core.json.Json.mapper.convertValue(json.getMap(), cls)
  5. 0

    Je pense que l'utilisation de Gson comme vous l'avez décrit est la meilleure solution possible à l'heure actuelle.

    Alors que je suis d'accord que si un protocole de couche a été inclus dans le Vert.x en effet, il serait le premier prix, à l'aide de Gson maintient votre serveur internes assez organisé et il est peu probable d'être le goulot d'étranglement des performances.

    Si et seulement si cette stratégie devient le goulot d'étranglement des performances avez-vous atteint le point de concevoir une meilleure solution. Rien avant que c'est prématuré d'optimisation.

    Mes deux cents.