Hibernate vs JPA vs JDO - плюси і мінуси кожного? [зачинено]

Я знайомий з ORM як концепцією, і я навіть кілька років тому навіть використовував nHibernate для проекту .NET; однак я не встиг за темою ORM на Java і не мав можливості скористатися жодним із цих інструментів.

Але тепер, можливо, я маю шанс почати використовувати деякі засоби ORM для одного з наших додатків, намагаючись відійти від низки застарілих веб-служб.

Мені важко розповісти різницю між специфікацією JPA, що ви отримуєте з самої Hibernate бібліотеки та що може запропонувати JDO.

Отже, я розумію, що це питання є дещо відкритим, але я сподівався отримати певну думку щодо:

• Які плюси і мінуси кожного?
• Що б ви запропонували для нового проекту?
• Чи є певні умови, коли було б сенс використовувати один фреймворк проти іншого?

Деякі примітки:

• JDO та JPA - це специфікація, а не реалізація.
• Ідея полягає в тому, що ви можете обмінятись реалізаціями JPA, якщо ви обмежите свій код лише стандартними JPA. (Дітто для JDO.)
• Hibernate може бути використаний як одна така реалізація JPA.
• Однак, Hibernate пропонує вбудований API з функціями, що перевищують та перевищують функції JPA.

ІМО, я б рекомендував зимувати.

Були деякі коментарі / запитання щодо того, що вам потрібно робити, якщо вам потрібно використовувати функції, пов’язані зі сном. Є багато способів переглянути це, але моя порада буде:

• Якщо вас не турбує перспектива підключення постачальника, тоді зробіть вибір між режимом hibernate та іншими реалізаціями JPA та JDO, включаючи різні розширення для конкретних постачальників у процесі прийняття рішень.

• Якщо вас турбує перспектива підключення постачальника, і ви не можете використовувати JPA, не вдаючись до конкретних розширень для постачальника, тоді не використовуйте JPA. (Дітто для JDO).

Насправді вам, ймовірно, доведеться компенсувати, наскільки ви турбуєтесь про зв’язування постачальника та наскільки вам потрібні ці розширення для конкретних постачальників.

І є й інші фактори, наприклад, наскільки добре ви / ваш персонал знаєте відповідні технології, скільки коштуватиме продукція при ліцензуванні та чию історію ви вірите в те, що буде в майбутньому для JDO та JPA.

Переконайтесь, що ви оцінюєте реалізацію JDO DataNucleus. Ми розпочали роботу зі сплячки, тому що вона виявилася такою популярною, але досить скоро зрозуміла, що це не 100% прозоре рішення. Занадто багато застережень, і документація наповнена "якщо у вас є така ситуація, то ви повинні написати свій код так", який позбавив задоволення від вільного моделювання та кодування, як би ми не хотіли. JDO ніколи не змушував мене коригувати свій код або свою модель, щоб змусити його працювати «належним чином». Я можу просто спроектувати та кодувати прості POJO так, як ніби я збираюся використовувати їх лише «у пам’яті», але я можу зберігати їх прозоро.

Інша перевага JDO / DataNucleus перед сплячим режимом полягає в тому, що він не має всіх витрат на відображення часу запуску і є більш ефективним у пам’яті, оскільки використовує поліпшення коду байтового часу збірки (можливо, додайте 1 сек до свого часу збирання для великого проекту) ніж відображення часу роботи в сплячому режимі на основі схеми проксі-сервера.

Інша річ, яку ви можете роздратувати у сплячому режимі, - це те, що ви посилаєтесь на те, що ви вважаєте об'єктом ... це часто "проксі" для об'єкта. Без переваги покращення байтового коду необхідний шаблон проксі-сервера, щоб дозволити завантаження на вимогу (тобто уникати потягування всього графіку об'єкта, коли ви тягнете об'єкт верхнього рівня). Будьте готові до вибору рівних та хеш-коду, тому що об'єкт, на який ви посилаєтесь, часто є лише проксі-сервером цього об’єкта.

Ось приклад розладів, які ви отримаєте зі сплячки, які ви не отримаєте з JDO:

http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53

Якщо вам подобається кодування на "обхідні шляхи", тоді, звичайно, "Зимовий режим" для вас. Якщо ви цінуєте чисту, чисту, орієнтовану на об'єкти, розробку, орієнтовану на модель, де ви витрачаєте весь свій час на моделювання, дизайн та кодування, і жодне з них на некрасиві способи вирішення проблем, тоді витрачайте кілька годин на оцінку JDO / DataNucleus . Вкладені години будуть погашені в тисячу разів.

Оновлення лютого 2017 року

Даний час DataNucleus 'впроваджує стандарт стійкості JPA на додаток до стандарту JDO-стійкості, тому перенесення існуючих проектів JPA від сплячого до DataNucleus повинно бути дуже прямим вперед, і ви можете отримати всі вищезгадані переваги DataNucleus з дуже невеликою зміною коду. , якщо якийсь. Тож, з точки зору питання, вибір конкретного стандарту, JPA (тільки RDBMS) проти JDO (RDBMS + Ні SQL + ODBMSes + інші), DataNucleus підтримує обидва, Hibernate обмежується лише JPA.

Продуктивність оновлень СБ у сплячому режимі

Ще одне питання, яке слід враховувати при виборі ОРМ, - це ефективність його брудного механізму перевірки - що стає дуже важливим, коли йому потрібно побудувати SQL для оновлення об'єктів, які змінилися в поточній транзакції - особливо, коли об'єктів багато. Детальний технічний опис механізму брудної перевірки Hibernate в цій відповіді ТА : JPA із вставкою HIBERNATE дуже повільно

Нещодавно я оцінив і обрав постійну основу для проекту java, і мої висновки такі:

Я бачу, що підтримка на користь JDO полягає насамперед:

• ви можете використовувати не-sql джерела даних, db4o, hbase, ldap, bigtable, couchdb (плагіни для кассандри) тощо.
• ви можете легко перейти з sql на не-sql джерело даних і навпаки.
• немає проксі-об'єктів і, отже, менше болю щодо хеш-коду () та рівності () реалізації
• більше POJO і, отже, потрібно менше обхідних шляхів
• підтримує більше типів відносин і полів

і підтримка на користь JPA полягає насамперед:

• більш популярні
• jdo мертвий
• не використовує розширення байт-коду

Я бачу багато публікацій про JPA від розробників JPA, які явно не використовували JDO / Datanucleus, пропонуючи слабкі аргументи за те, щоб не використовувати JDO.

Я також бачу багато публікацій від користувачів JDO, які перейшли до JDO і в результаті набагато щасливіші.

Що стосується популярності JPA, то, здається, це частково пояснюється підтримкою постачальників RDBMS, а не технічно перевершує. (Мені звучить як VHS / Betamax).

JDO та його посилання на реалізацію Datanucleus явно не мертві, як показано прийняттям Google від Google для GAE та активної розробки вихідного коду (http://sourceforge.net/projects/datanucleus/).

Я бачив ряд скарг на JDO через розширення байт-коду, але поки немає пояснень, чому це погано.

Насправді, у світі, який стає все більш одержимим рішеннями NoSQL, JDO (та реалізація данихнуклеусів) здається набагато безпечнішою.

Щойно я почав використовувати JDO / Datanucleus і налаштував його так, щоб я міг легко перемикатися між використанням db4o та mysql. Для швидкої розробки корисно використовувати db4o і не надто турбуватися про схему БД, а потім, як тільки схема стабілізується, розгортається до бази даних. Я також впевнений, що пізніше я міг би розгорнути всю / частину своєї програми до GAE або скористатися розподіленим сховищем / картою-зменшити а-ля hbase / hadoop / cassandra, не надто багато рефакторингу.

Я знайшов початкові перешкоди для початку роботи з Datanucleus трохи складними - Документація на веб-сайті datanucleus трохи важко потрапити - підручники не так легко виконувати, як хотілося б. Сказавши це, більш детальна документація щодо API та картографування є дуже хорошою, як тільки ви пройдете початкову криву навчання.

Відповідь - це залежить від того, що ви хочете. Я б скоріше мав чистіший код, не-постачальник-блокування, більш орієнтований на pojo, ноші-вірші, варіанти віршів більш популярні.

Якщо ви хочете відчути тепле метушливе відчуття, що ви робите так само, як і більшість інших розробників / овець, виберіть JPA / сплячку. Якщо ви хочете лідирувати у своїй галузі, пробний диск JDO / Datanucleus і зробіть свій власний розум.

Що б ви запропонували для нового проекту?

Я б не запропонував жодного! Використовуйте Spring DAO JdbcTemplateразом із StoredProcedure, RowMapperа RowCallbackHandlerзамість цього.

Мій власний досвід роботи зі сплячим режимом полягає в тому, що заощаджений час передує більш ніж компенсовано нескінченними днями, які ви витратите вниз, намагаючись зрозуміти та налагодити такі проблеми, як несподівана каскадна поведінка оновлення.

Якщо ви використовуєте реляційну БД, то чим ближче ваш код, тим більше контролю у вас є. Шар DAO Spring забезпечує точний контроль шару відображення, при цьому видаляючи потребу в кодовому шаблоні. Крім того, він інтегрується в транзакційний шар Spring, що означає, що ви можете дуже легко додати (через AOP) складну трансакційну поведінку, не вторгнувшись у ваш код (звичайно, ви отримуєте це також із Hibernate).

JDO мертвий

JDO насправді не мертвий, тому, будь ласка, перевірте свої факти. JDO 2.2 був випущений в жовтні 2008 р. JDO 2.3 знаходиться на стадії розробки.

Це розроблено відкрито, під Apache. Більше випусків, ніж у JPA, і його специфікація ORM все ще наперед, навіть запропоновані JPA2 функції

JDO має розширені функції, ніж JPA, див. Http://db.apache.org/jdo/jdo_v_jpa.html

Я використовую JPA (реалізація OpenJPA від Apache, що базується на кодовій базі KODO JDO, якій більше 5 років і надзвичайно швидко / надійно). ІМХО кожен, хто скаже вам обійти характеристики, дає вам погану пораду. Я вклав час і був неодмінно нагороджений. За допомогою JDO або JPA ви можете змінити постачальників з мінімальними змінами (JPA має відображення в ормах, тому ми говоримо менше, ніж день, щоб можливо змінити постачальників). Якщо у вас є 100+ таблиць, як у мене, це величезна кількість. Крім того, ви отримуєте вбудований кеш-пам'ять з вилученням кеш-кластера та його всім хорошим. SQL / Jdbc чудово підходить для високоефективних запитів, але прозора наполегливість набагато перевершує написання алгоритмів і процедур введення даних. У мене всього 16 запитів SQL у всій моїй системі (50 к + рядків коду).

Я сам розглядав це і не можу знайти різницю між ними. Я думаю, що великий вибір полягає в тому, в якій реалізації ви використовуєте. Я сам розглядав платформу DataNucleus, оскільки це агностична реалізація обох даних.

Кожен, хто каже, що JDO мертвий, є астротурфінгом, який це знає.

JDO живий і здоровий. Технічні характеристики все ще є більш потужними, зрілими та вдосконаленими, ніж значно більш молодий та стриманий JPA.

Якщо ви хочете обмежитися лише тим, що є у стандарті JPA, ви можете написати в JPA і використовувати DataNucleus як більш високу продуктивність, більш прозору реалізацію стійкості, ніж інші реалізації JPA. Звичайно, DataNucleus також реалізує стандарт JDO, якщо ви хочете гнучкість та ефективність моделювання, що приносить JDO.

Я використовував Hibernate (реалізація JPA) та JPOX (реалізація JDO) в одному проекті. JPOX спрацював нормально, але зіткнувся з помилками досить швидко, там, де деякі функції Java 5 мови він не підтримував у той час. У нього виникли проблеми з приємною грою з транзакціями XA. Я генерував схему бази даних з об'єктів JDO. Він хотів підключатися до бази даних кожного разу, що дратує, якщо ваше з'єднання Oracle не працює.

Потім ми перейшли до режиму сплячки. Ми розгулювались із просто використанням чистої JPA на деякий час, але нам потрібно було використовувати деякі особливості сплячого режиму, щоб зробити карти. Запустити один і той же код на кількох базах даних дуже просто. Здається, сплячий режим кешує об'єкти агресивно або просто має дивну поведінку кешування часом. Існує декілька конструкцій DDL, які Hibernate не можуть обробити, і тому вони визначаються в додатковому файлі, який запускається для ініціалізації бази даних. Коли я зіткнувся зі сплячою проблемою, часто багато людей стикаються з тією ж проблемою, що полегшує гуглінг за рішенням. Нарешті, сплячка здається добре розробленою та надійною.

Деякі інші респонденти запропонували просто використовувати SQL. Справжній випадок використання вбивць для реляційного відображення об'єктів - це тестування та розробка. Бази даних, створені для обробки великого обсягу даних, як правило, дорогі і їх важко встановити. З ними складно перевірити. Існує безліч баз даних Java в пам'яті, які можна використовувати для тестування, але, як правило, марні для виробництва. Можливість використовувати реальну, але обмежену базу даних, підвищить продуктивність розробки та надійність коду.

Я зробив зразок WebApp у травні 2012 року, який використовує JDO 3.0 та DataNucleus 3.0 - подивіться, наскільки він чистий: https://github.com/TorbenVesterager/BadAssWebApp

Гаразд, можливо, це занадто чисто, тому що я використовую POJO як для бази даних, так і для клієнта JSON, але це весело :)

PS: Містить кілька приміток SuppressWarnings (розроблено в IntelliJ 11)