95 votes

Quel est l'intérêt des classes ObjectFactory de JAXB 2 ?

Je suis novice dans l'utilisation de JAXB et j'ai utilisé xjc de JAXB 2.1.3 pour générer un ensemble de classes à partir de mon schéma XML. En plus de générer une classe pour chaque élément de mon schéma, il a créé une classe ObjectFactory.

Il semble que rien ne m'empêche d'instancier les éléments directement, par ex.

MyElement element = new MyElement();

alors que les tutoriels semblent préférer

MyElement element = new ObjectFactory().createMyElement();

Si je regarde dans ObjectFactory.java, je vois :

public MyElement createMyElement() {
    return new MyElement();
}

Alors, quel est le problème ? Pourquoi devrais-je prendre la peine de conserver la classe ObjectFactory ? Je suppose qu'elle sera également écrasée si je devais recompiler à partir d'un schéma modifié.

66voto

Chris Jester-Young Points 102876

La rétrocompatibilité n'est pas la seule raison :-P

Avec des schémas plus compliqués, comme ceux qui ont des contraintes compliquées sur les valeurs que le contenu d'un élément peut prendre, vous devez parfois créer de véritables JAXBElement objets. En général, il n'est pas facile de les créer à la main. create* font le travail à votre place. Exemple (tiré du schéma XHTML 1.1) :

@XmlElementDecl(namespace = "http://www.w3.org/1999/xhtml", name = "style", scope = XhtmlHeadType.class)
public JAXBElement<XhtmlStyleType> createXhtmlHeadTypeStyle(XhtmlStyleType value) {
    return new JAXBElement<XhtmlStyleType>(_XhtmlHeadTypeStyle_QNAME, XhtmlStyleType.class, XhtmlHeadType.class, value);
}

C'est ainsi que vous obtenez un <style> dans un <head> étiquette :

ObjectFactory factory = new ObjectFactory();
XhtmlHtmlType html = factory.createXhtmlHtmlType();
XhtmlHeadType head = factory.createXhtmlHeadType();
html.setHead(head);
XhtmlStyleType style = factory.createXhtmlStyleType();
head.getContent().add(factory.createXhtmlHeadTypeStyle(style));

Les trois premières utilisations de l ObjectFactory pourrait être considérée comme superflue (bien qu'utile pour la cohérence), mais la quatrième rend JAXB beaucoup, beaucoup plus facile à utiliser. Le fait d'avoir à écrire un new JAXBElement à la main à chaque fois !

38voto

skaffman Points 197885

Comme l'a souligné @Chris, il arrive que JAXB ne puisse pas fonctionner avec les POJO, car le schéma ne peut pas être transposé exactement en Java. Dans ces cas, JAXBElement Les objets wrapper sont nécessaires pour fournir les informations supplémentaires sur le type.

Il y a deux exemples concrets que j'ai rencontrés où cela est courant.

  • Si vous voulez marshaler un objet d'une classe qui n'a pas l'attribut @XmlRootElement annotation. Par défaut, XJC ne génère que des @XmlRootElement pour certains éléments, et pas pour d'autres. La logique exacte de ceci est un peu compliquée, mais vous pouvez forcer XJC à générer plus de @XmlRootElement en utilisant l'option "mode de liaison simple"

  • Lorsque votre schéma utilise des groupes de substitution. Il s'agit d'une utilisation assez avancée du schéma, mais XJC traduit les groupes de substitution en Java en faisant un usage intensif de la fonction JAXBElement enveloppes.

Donc, dans un modèle d'objet généré par XJC qui fait un usage intensif de JAXBElement (quelle qu'en soit la raison), vous devez trouver un moyen de construire ces JAXBElement instances. La génération ObjectFactory est de loin le moyen le plus simple de le faire. Vous peut Vous pouvez les construire vous-même, mais c'est une tâche fastidieuse et sujette aux erreurs.

9voto

Bert F Points 27237

La rétrocompatibilité, je suppose ...

http://weblogs.java.net/blog/kohsuke/archive/2005/08/a_story_of_migr.html :

...Plus de ObjectFactory.createXYZ. Le problème avec ces méthodes d'usine était qu'elles lançaient une JAXBException. Maintenant, vous pouvez simplement faire new XYZ(), plus de blocs try/catch. (Je sais, je sais, ... c'est l'un de ces "qu'est-ce qu'on a pensé ? ces "à quoi on pensait !?" choses)...

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X