JAXB - Бобы к XSD или XSD к бобам?
У меня есть существующая модель данных. Я хотел бы выразить эту модель данных с точки зрения XML.
Похоже, что у меня есть две опции, если я должен использовать JAXB:
- Создайте XSD, который зеркально отражает мою модель данных, и используйте xjc для создания объектов привязки. Маршалинг и немаршалинг включат создание "отображающегося" класса, который взял бы мои существующие объекты данных и отобразил бы их на объекты это созданный xjc. Например, в моей модели данных у меня есть класс Doc, и JAXB создал бы другой класс Doc с в основном теми же точными полями, и я должен буду отобразиться от своего класса Doc до класса Doc xjc.
- Аннотируйте мою существующую модель данных аннотациями JAXB и используйте schemagen для генерации XSD от моих аннотируемых классов.
Я вижу advantanges и недостатки обоих подходов. Кажется, что большинство людей, использующих JAXB, запускает с файла XSD. Это имеет смысл, что XSD должен быть истиной золотого стандарта, так как это выражает модель данных действительно межплатформенным способом.
Я склонен запуститься с XSD сначала, но это кажется неприглядным, что я должен записать и поддержать отдельный класс отображения что данные шаттлов, промежуточные мой мир и мир JAXB.
Какие-либо рекомендации?
5 ответов
Создание XSD из существующих классов кажется мне наиболее безопасным.
Однако мне кажется, что если вы не знаете JAXB хорошо, то подход с аннотированием ваших собственных классов может оказаться чрезвычайно разочаровывающим (как в боли, так и во времени :)).
Это случилось со мной в связанном контексте, когда я пытался вручную извлечь суперкласс из классов, сгенерированных JAXB, а затем упорядочить экземпляры в XML. Я получал различные (загадочные) исключения JAXB. Правда, мои познания в JAXB еще не очень глубоки.
Если вы настаиваете на использовании JAXB, я предлагаю рассмотреть возможность использования первого подхода (XSD + XJC) как способа получения начальных аннотаций JAXB для ваших классов.
Вы можете использовать XSD + XJC, чтобы понять, как аннотировать свои собственные классы. Затем вы можете попытаться разместить на них правильные аннотации. Начните с более сложных классов (ссылки, наследование, список ссылок, список ссылок на абстрактный базовый класс) на ранней стадии.
Использование другой технологии для генерации XSD из неаннотированных классов в качестве толчка для XSD может помочь. Или вы можете выбрать XSD, который охватывает большую часть того, что используют ваши классы.
Если целью этих усилий является также возможность маршалинга экземпляров в XML, то я предлагаю внимательно следить за JAXBElement. В некоторых случаях (которые я не могу указать из-за недостатка знаний) экземпляры не будут маршалироваться, если они не заключены в JAXBElement.
Мы используем HyperJAXB для создания уровня сохраняемости на основе набора XSD. Сгенерированные классы также используются для маршалинга. У нас много "веселья", чтобы заставить это работать, особенно. из-за IDREF и JAXBElement.
Вы можете использовать xjc и по-прежнему иметь только один класс с аннотациями XML, который будет использоваться как объект данных. Но это на тот случай, если вы не создаете заново классы для каждой сборки.
И поскольку генерация кода, на мой взгляд, такова, в вопросе о том, с чего начать, я бы предложил начать с классов. Потому что, если у вас есть классы в качестве отправной точки, вам никогда не потребуется повторно генерировать эти классы. И со временем ваши классы начинают расти - включая @XmlTransient , наследование, вспомогательные методы и другие (JPA) аннотации.
Вы находитесь в худшей из возможных отправных точек для JAXB. В вашей позиции, я думаю, JiBX может быть лучше, он может генерировать схему из модели классов без аннотаций, а затем обратно связывать XML с объектной моделью во время выполнения без использования аннотаций.
Решение, которое мы выбрали, - создать отдельный проект, содержащий все модели данных, определенные схемами xml, из которых классы java производятся с использованием JAXB. Другие проекты, использующие модели данных, зависят от этого пакета схем.
Таким образом, все «контракты» между проектами определяются в одном месте с использованием удобного переносимого xsd-представления. Нет необходимости в каких-либо классах сопоставления, потому что мы просто напрямую используем сгенерированные JAXB.
Читая между строк, я считаю, что верно следующее:
- У вас есть желаемая объектная модель.
- У вас есть желаемая XML-схема или, по крайней мере, довольно хорошее представление о том, как вы хотите, чтобы она выглядела.
Этот сценарий обычно упоминается как отображение «встречи посередине». JAXB решает эту проблему лишь частично. К счастью, поскольку JAXB является спецификацией, вы можете использовать и другие реализации, такие как EclipseLink JAXB (MOXy).
MOXy предлагает расширение сопоставления на основе XPath, которое позволяет сопоставлять имеющуюся модель Java и требуемую схему XML: