hibernate & JAXB / JSON (модель сообщений и модель данных)

Question

Это вопрос философии дизайна о том, как тесно связать обмен сообщениями с вашей моделью данных.

Учитывая объект pojo, я могу аннотировать его аннотациями Hibernate, JAXB и JSON, чтобы тот же класс могбыть записанным в базу данных, а также сериализовать / десериализовать для обмена сообщениями.Фактор удобства в этом действительно высок, потому что это означает, что мне не нужно писать классы перевода для преобразования сообщений в классы, которые используются для базы данных (что очень важно для утомительного обслуживания и обслуживания).

Тем не менее, это всегда беспокоило меня, потому что оно тесно связывает ваш интерфейс и сообщения со структурой и дизайном вашей модели данных.Для определенных типов приложений сообщения могут быть именно тем, что вы хотите сохранить в базе данных, а в других случаях это подмножество полей базы данных.

Есть ли лучший способ отделить их, не подвергая себя утомительнымперевод / преобразование классов?Есть ли шаблон, который я могу использовать, чтобы как минимум лучше связать сообщение и данные?

Answer 1

Вы можете использовать расширение @XmlPath в EclipseLink JAXB (MOXy), чтобы разорвать связь между тогда существующей моделью и форматом сообщения (я технический руководитель MOXy):

• JAXB2: отображение вложенных элементов в один и тот же класс Java

Answer 2

Я полностью согласен с вашей озабоченностью ... это одна серая область, потому что она действительно зависит от проблем вашего домена, которые вы пытаетесь решить.

Если ваш проект простой и понятный, тогда я могу просто аннотировать сущности и все будет готово. Таким образом, потребитель (например, код Javascript) в основном выбирает данные, необходимые для отображения на странице. В этом случае вы отвечаете за чтение JSON / XML и делаете все, что захотите.

Однако, если вы пишете веб-сервисы для других людей, данные обычно поступают из разных объектов (объединений таблиц). В этом случае нет смысла возвращать такой сложный JSON / XML, который так тесно связан с реальной структурой сущности. Если вы решите провести рефакторинг своих организаций в один прекрасный день, то все ваши потребители будут подвержены негативному воздействию. Таким образом, лучше создавать отдельные компоненты, отражающие обобщенные данные, предназначенные для потребителей, а не полагаться на существующие сущностные компоненты. Таким образом, сгенерированный JSON / XML сможет противостоять будущим изменениям и минимизирует отрицательный волновой эффект.