Использование одних и тех же классов Entity в разных репозиториях данных Spring

Я пытаюсь собрать проект, в котором мне нужно сохранить некоторые классы сущностей, используя разные репозитории данных Spring (gemfire, jpa, mongodb и т. д.). Поскольку данные более или менее одинаковы, которые должны поступать в эти репозитории, мне было интересно, могу ли я использовать один и тот же класс сущностей для всех из них, чтобы избавить меня от преобразования одного объекта в другой?

У меня это работает для gemfire и jpa, но класс сущности уже начинает выглядеть немного запутанным.

@Id // spring-data-gemfire
@javax.persistence.Id // jpa
@GeneratedValue
private Long id;

Пока вижу следующие варианты:

  1. Создайте интерфейс на основе отдельных классов Entity (доменов). Попытка повторно использовать один и тот же класс выглядит как преждевременная оптимизация.
  2. Экстернализировать сопоставление на основе xml для JPA, не уверен, можно ли экстернализовать сопоставление gemfire и mongodb.
  3. Используйте разные конкретные классы сущностей и используйте некоторый конструктор/конвертер копирования для преобразования.

Буквально бился головой о стену, чтобы найти лучший подход - любой ответ очень ценен. Спасибо


java spring-data spring-data-jpa spring-data-mongodb spring-data-gemfire
person andrew    schedule 24.05.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Если под словом «странно» вы имеете в виду, что объекты/классы сущностей вашего домена приложения начинают накапливать много разных, но отдельных (отображающих) аннотаций (некоторые даже семантически одинаковы, например, o.s.data.annotation.Id SD Common и @javax.persistence.Id JPA) для разных хранилищ данных, в которых эти сущности будет сохраняться, то я полагаю, что это понятно.

Загрязнение аннотаций только увеличивается по мере увеличения количества представлений для ваших сущностей. Например, подумайте об аннотациях Джексона для сопоставления JSON или JAXB для XML и т. д. Довольно скоро у вас будет больше метаданных, чем фактических данных, :-)

Впрочем, это больше вопрос предпочтений, удобства, простоты, на самом деле.

Некоторые разработчики являются пуристами и любят все экстернализировать. Другим нравится хранить информацию (метаданные) рядом с кодом, использующим ее. Появились даже определенные шаблоны для решения подобных проблем... DTO, ограниченные контексты (см. Fowler BoundedContext, тесно связанный с DDD и микросервисами).

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

  1. Простота
  2. Последовательность
  3. СУХОЙ
  4. Контрольная работа
  5. Рефакторинг

(наряду с некоторыми другими... хороший OOD, SoC, SOLID, шаблоны проектирования и т. д.).

В том же порядке. Если что-то становится слишком сложным, проведите рефакторинг и упростите его. Будьте последовательны в том, что вы делаете, следуя/используя шаблоны, соглашения; Знакомство — это 1 ключ к последовательности. Но и не повторяйтесь.

В конце концов, речь идет о поддержке приложения. Сможет ли кто-то еще, кто продолжит с того места, где вы остановились, быстро понять организацию и логику и сохранить их... простота превыше всего. Это не означает, что он настолько прост, что нежизнеспособен или ценен. Даже сложные вещи могут быть простыми, если их правильно организовать. Однако разбивка вещей на части и введение абстракций могут иметь скрытые издержки (см. заключительные мысли).

Чтобы более конкретно ответить (несколько) на ваши вопросы...

  1. Я не уверен насчет MongoDB, но (Spring Data) GemFire ​​не имеет внешнего сопоставления. Требуются как минимум @Region (в классе сущностей) и @Id, а также @PersistenceConstructor, если ваш класс сущностей имеет более 1 конструктора. Для пример.

  2. Это похоже на DTO. Лично я считаю, что BoundContexts — это лучшая и более естественная модель данных приложения, поскольку модель предметной области не должна быть чрезмерно привязана к какому-либо постоянному хранилищу или внешнему представлению (например, JSON, XML и т. д.). Модель предметной области приложения является 1 истинным состоянием приложения, и она должна моделировать концепцию, которая представлена ​​естественным образом, а не поверхностно, чтобы удовлетворить какое-либо представление или постоянное хранилище (отсюда отображение/преобразование).

В любом случае, постарайтесь не корить себя слишком сильно. Все дело в управлении сложностью. Попробуйте позволить себе просто делать и использовать тестирование и другие циклы обратной связи, чтобы найти ответ, который подходит для вашего приложения. Вы узнаете.

Надеюсь это поможет.

person John Blum    schedule 25.05.2016
comment
Большое спасибо, @john явно наводит на размышления и проницателен. Я думаю, мне нужно более внимательно изучить DDD/BoundedContext. Я предполагаю, что часть проблемы, которая вызвала меня, связана с тем, что я принадлежу к группе разработчиков-пуристов, которым нравится все экстернализовать, как вы упомянули. Думаю, мне нужно немного отпустить это и жить с некоторыми загрязненными метаданными. Я попытаюсь развить его немного дальше, как вы упомянули, - обновлю эту ветку результатами других циклов обратной связи. Спасибо еще раз. - person andrew; 25.05.2016