Я раньше не использовал Spring Data, но я использовал Hibernate ORM несколько раз для приложения на основе MySQL. Я просто не понимаю, какую структуру выбрать между ними для приложения на основе MongoDB.
Я попытался найти ответ, но не могу найти ответ, который делает сравнение между ними в производственной среде. Кто-нибудь нашел проблемы с этими двумя структурами с MongoDB?
Отказ от ответственности: я возглавляю проект данных Spring Data, поэтому я в основном рассмотрю часть данных Spring Data here:
Я думаю, что основное различие между этими двумя проектами состоит в том, что команда OGM Hibernate решила сосредоточить свои усилия на JPA, а команда Spring Data явно не сделала этого. Причины таковы:
Таким образом, с помощью Spring Data мы предпочли скорее обеспечить согласованную модель программирования для поддерживаемых хранилищ, но не пытаться заставить все в один избыточный аббревиатурный API: вы получаете хорошо известные реализации шаблонов, вы получаете абстракцию репозитория, который работает одинаково для всех магазинов, но позволяет вам использовать специальные функции и концепции магазина.
Отказ от ответственности: я являюсь одним из разработчиков OGM Hibernate, поэтому я попытаюсь объяснить некоторые причины этого.
Hibernate OGM обеспечивает поддержку Java Persistence (JPA) для решений NoSQL. Он повторно использует движок Hibernate ORMs, но сохраняет объекты в хранилище данных NoSQL вместо реляционной базы данных. Он также направлен на предоставление доступа к конкретным функциям хранилища данных, когда JPA не имеет хорошей подгонки.
Этот подход интересен по нескольким причинам:
Известные семантические и API-интерфейсы. Разработчики Java уже знакомы с JPA, это означает, что не нужно изучать API нижнего уровня. Он также поддерживает как HQL, так и собственные бэкэнд-запросы.
Поздний выбор бэкэнд. Выбор правильного хранилища данных NoSQL не является тривиальным. С Hibernate OGM вам не придется совершать какое-либо конкретное решение NoSQL, и вы сможете легко переключаться и тестировать разные серверы.
Существующие инструменты и библиотеки. JPA и Hibernate ORM существуют некоторое время, и вы сможете повторно использовать библиотеки и инструменты, которые их используют под ними.
Большая часть логической модели JPA подходит. Примером хорошей подгонки является @Embedded, @EmbeddedCollection и @Entity (это может быть node, документ или кеш, основанный на выбранном хранилище данных). По общему признанию, имена аннотаций могут быть странными, потому что вам также придется иметь дело с @Table и @Column.
Сохранение рефератов JPA на уровне объектов, оставляя место для множества трюков и оптимизаций. У нас запланировано несколько идей, таких как сохранение полиглота: хранение данных в нескольких хранилищах данных и использование лучшего для конкретного задания на чтение.
Основной недостаток заключается в том, что некоторые из понятий JPA не легко отображаются в мир NoSQL: транзакции, например. Пока у вас будет доступ к методам демаркации транзакций, вы не сможете откатываться от хранилищ данных, которые не поддерживают транзакции изначально (транзакции в этом случае будут использоваться для группировки операций и оптимизации количества вызовов db).
Кроме того, если ваш набор данных по своей природе ориентирован не на модель, то Hibernate OGM не для вас.
Можно просто пойти с SpringData. Если вы помните, Spring ORM также использует некоторые элементы JPA, такие как Entity, Transaction, и обеспечивает наилучшее сочетание элементов из JPA и Hibernate API a. Сообщество Spring позаботится о будущих версиях, если JPA станет более зрелой для NoSQL. Хотя это не главная причина. Большинство причин описаны @Oliver Drotbohm. Прочитайте дополнительную документацию по SprinData и проанализируйте свою модель данных, масштабируемость по непрерывности/росту хранилища данных, найдите наиболее подходящее для вашего решения решение и рассмотрите предложение, данное @Davide. Во многих случаях SpringData имеет большую вероятность успеха, чем JPA, при интеграции с MongoDB.