У меня есть корпоративное приложение Java, которое предоставляет веб-службу, имеет уровень домена и уровень сохранения hibernate. В этом конкретном случае между объектами, которые я отправляю по проводу, объектам домена и объектам сохранения, нет огромной разницы (на данный момент).
В настоящее время приложение использует DTO на стороне персистенции и аннотирует классы домена с аннотациями JAXB. Однако, чем больше я читаю и думаю об этом, тем больше это кажется обратным! (Не говоря уже о том, что существует много кода для поддержки бессмысленных взад и вперед между объектами DTO и Domain). Похоже, что большинство архитекторов предлагают помещать аннотации JPA в модель домена и создавать DTO для отправки объектов по кабелю.
В моем случае могу ли я разместить аннотации JAXB и JPA (Hibernate) на своих классах доменов?
Мысль о том, что мой фасад веб-сервиса, мой домен и моя настойчивость тесно связаны друг с другом, кажутся легкими в обслуживании, но меня это волнует, поскольку они могут со временем меняться. Но было бы разумнее создать набор классов DTO для стороны веб-служб и пропустить DTO для стороны сохранения?
Нет никакой функциональной причины для того, чтобы не аннотировать один и тот же класс с аннотациями JPA и JAXB, я делал это сам по случаю. Это становится немного трудно читать, хотя, и иногда вам нужны разные компромиссы дизайна класса с JAXB и JPA. По моему опыту, эти компромиссы обычно означают, что вы получаете две модели классов.
Я согласен, что использование тех же классов моделей - правильный подход. Если вас беспокоит беспорядок аннотаций, вы можете использовать реализацию JAXB (например, EclipseLink JAXB), которая обеспечивает механизм для экстернализации метаданных:
Также, поскольку вы используете модель JPA, EclipseLink JAXB (MOXy) имеет расширения для упрощения:
Ниже приведен пример использования одной модели с JAXB и JPA для создания службы RESTful:
Нет проблем с использованием обеих аннотаций в одном классе. Я даже склонен поощрять это, потому что вам не нужно копировать-вставлять, когда происходят изменения.
В некоторых случаях некоторые свойства отличаются поведением - например, автогенерированный идентификатор может не потребоваться для сортировки. @XmlTransient и @Transient затем объединяются. Это становится немного трудно читать, но не слишком сложно, потому что очевидно, что означают все аннотации.
Кто-нибудь соблазн поместить атомарные объекты ссылок в ваш постоянный домен, потому что вы взяли на себя обязательство определять структуру xml-структуры вашего веб-сервиса? Мне кажется странным это делать. Ссылки Hateoas кажутся хорошей идеей, но сохраняемый домен и служба impl (а не веб-сервис) не интересуются ссылками на атомы. Опять же, использование аннотаций xml и использование jersey для сериализации моего домена для меня, безусловно, удобно. Другим недостатком этого подхода является то, что он легко влияет на пользователей веб-сервисов во время выполнения с рефакторингом домена "уровень".
Я знаю, что этот вопрос немного устарел, но я думал, что буду взвешивать, так как это проблема, с которой я недавно столкнулся. Моя рекомендация заключалась бы в том, чтобы оставить только аннотированные классы JAXB, так как любое изменение схемы потребует повторного создания этих классов. Это означает, что вам придется повторно вводить аннотации гибернации и т.д. Вручную. Это может быть немного устаревшим решением, но я думаю, что было бы вполне разумно создать файл сопоставления спящего режима (.hbm.xml), чтобы размещать внешние сопоставления. Это немного более гибкий, менее загроможденный и столь же полезный, на мой взгляд.