Jaki jest sens klas ObjectFactory JAXB 2?

Question 1

Jestem nowy w używaniu JAXB i użyłem xjc JAXB 2.1.3 do wygenerowania zestawu klas z mojego schematu XML. Oprócz wygenerowania klasy dla każdego elementu w moim schemacie, utworzono klasę ObjectFactory.

Wydaje się, że nic nie powstrzymuje mnie przed bezpośrednim tworzeniem instancji elementów, np

MyElement element = new MyElement();

podczas gdy samouczki wydają się preferować

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

Jeśli zajrzę do ObjectFactory.java, widzę:

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

więc o co chodzi? Dlaczego miałbym w ogóle zawracać sobie głowę utrzymywaniem klasy ObjectFactory? Zakładam, że zostanie on również nadpisany, gdybym miał ponownie skompilować ze zmienionego schematu.

Question 2

Kompatybilność wsteczna nie jest jedynym powodem. :-P

W przypadku bardziej skomplikowanych schematów, takich jak te, które mają skomplikowane ograniczenia dotyczące wartości, jakie może przyjąć zawartość elementu, czasami trzeba utworzyć rzeczywiste JAXBElementobiekty. Zwykle nie są one łatwe do wykonania ręcznie, więc create*metody wykonują ciężką pracę za Ciebie. Przykład (ze schematu 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);
}

Oto jak <style>umieścić tag w <head>tagu:

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));

Pierwsze trzy zastosowania ObjectFactorymożna by uznać za zbędne (choć przydatne dla spójności), ale czwarte z nich sprawia, że JAXB jest dużo, dużo łatwiejszy w użyciu. Wyobrazić sobie konieczność new JAXBElementręcznego wypisywania za każdym razem

Question 3

Jak zauważył @Chris, czasami JAXB nie może współpracować z POJO, ponieważ schemat nie może być dokładnie odwzorowany na Javę. W takich przypadkach JAXBElementobiekty opakowujące są niezbędne, aby zapewnić dodatkowe informacje o typie.

Są dwa konkretne przykłady, z którymi się spotkałem, gdzie jest to powszechne.

Jeśli chcesz zorganizować obiekt klasy, która nie ma @XmlRootElementadnotacji. Domyślnie XJC generuje tylko @XmlRootElementdla niektórych elementów, a nie dla innych. Dokładna logika tego jest nieco skomplikowana, ale możesz zmusić XJC do wygenerowania większej liczby @XmlRootElementklas przy użyciu „trybu prostego wiązania”
Kiedy Twój schemat używa grup podstawników. Jest to dość zaawansowane użycie schematu, ale XJC tłumaczy grupy podstawień na Javę, intensywnie wykorzystując JAXBElementopakowania.

Tak więc w modelu obiektowym wygenerowanym przez XJC, który intensywnie wykorzystuje JAXBElement(z jakiegokolwiek powodu), potrzebujesz sposobu konstruowania tych JAXBElementinstancji. Wygenerowany ObjectFactoryjest zdecydowanie najłatwiejszym sposobem na zrobienie tego. Możesz je zbudować samodzielnie, ale jest to niezgrabne i podatne na błędy.

Question 4

Wydaje mi się, że kompatybilność wsteczna ...

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

... Nigdy więcej ObjectFactory.createXYZ. Problem z tymi metodami fabrycznymi polegał na tym, że rzucają sprawdzony wyjątek JAXBException. Teraz możesz po prostu wykonać nowe XYZ (), bez bloków try / catch. (Wiem, wiem, ... to jedna z tych rzeczy „o czym myśleliśmy !?”) ...