Яка різниця між JPA і Hibernate? [зачинено]

Я розумію, що JPA 2 - це специфікація, і Hibernate - це інструмент для ORM. Також я розумію, що Hibernate має більше можливостей, ніж JPA 2. Але з практичної точки зору, яка насправді різниця?

У мене є досвід використання iBatis, і зараз я намагаюся навчитися або в сплячому режимі, або в JPA2. Я взяв книгу Pro JPA2, і вона посилається на "постачальника JPA". Наприклад:

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

Це мене бентежить, тому у мене є кілька питань:

• Лише використовуючи JPA2, я можу отримати дані з БД, просто анотувавши мої POJO
• Чи повинен JPA2 використовуватися з "постачальником послуг JPA", наприклад, TopLink або сплячий режим? Якщо так, то яка користь від використання JPA2 + Hibernate порівняно з JPA2 або порівняно зі сплячим режимом?
• Чи можете ви порекомендувати хорошу практичну книгу JPA2. "Pro JPA2" схоже на Біблію та посилання на JPA2 (він не потрапляє до запитів до пізнішої половини книги). Чи є книга, яка застосовує підхід до вирішення проблеми JPA2?

Оскільки ви заявляєте, що JPA - це лише специфікація, тобто немає її реалізації. Ви можете коментувати свої заняття скільки завгодно за допомогою JAP-анотацій, однак без реалізації нічого не відбудеться. Розгляньте JPA як вказівки, яких слід дотримуватися, або як інтерфейс, тоді як реалізація JPA Hibernate - це код, який відповідає API, визначеному специфікацією JPA, і забезпечує функцію під капотом.

Коли ви використовуєте Hibernate з JPA, ви фактично використовуєте реалізацію Hibernate JPA. Перевага цього полягає в тому, що ви можете замінити реалізацію JPA в режимі Hibernate на іншу реалізацію специфікації JPA. Якщо ви використовуєте прямий сплячий режим, ви замикаєтесь на реалізації, оскільки інші ORM можуть використовувати різні методи / конфігурації та примітки, тому ви не можете просто перейти на інший ORM.

Для більш детального опису читайте мій запис у блозі .

JPA - танець, Hibernate - танцюрист.

Деякі речі занадто важко зрозуміти без історичної точки зору мови та розуміння JCP.

Часто зустрічаються треті сторони, які розробляють пакети, які виконують функцію або заповнюють прогалини, які не є частиною офіційного JDK. З різних причин ця функція може стати частиною Java JDK через JCP (Java Community Process)

Hibernate (у 2003 р.) Створив спосіб абстрагувати SQL та дозволив розробникам більше мислити щодо збережених об'єктів (ORM). Ви повідомляєте про сплячий режим про свої об'єкти Entity, і це автоматично генерує стратегію їх збереження. Hibernate забезпечив реалізацію для цього та API для керування реалізацією через конфігурацію XML або примітки.

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

Тим часом, JCP з великим вкладом від Hibernate та інших постачальників інструментів ORM розробляв JSR 220 (Запит специфікації Java), що призвело до JPA 1.0 (2006) і, врешті, JSR 317, що є JPA 2.0 (2009). Це специфікації загального API Persistent Java. API надається в JDK як набір інтерфейсів, щоб ваші класи могли залежати від javax.persistence і не турбуватися про конкретного постачальника, який виконує роботу зі збереженням ваших об'єктів. Це лише API, а не реалізація. Зимова сплячка стає одним з багатьох постачальників, які реалізують специфікацію JPA 2.0. Ви можете ввести код JPA і вибрати будь-який сумісний постачальник ORM відповідно до ваших потреб.

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

Джерело: http://www.reddit.com/r/java/comments/16ovek/understanding_when_to_use_jpa_vs_hibernate/

JPA - це інтерфейс, а "Hibernate" - це реалізація.

Традиційно існує декілька рішень Java ORM:

• Зимує
• TopLink
• JDO

кожна реалізація визначає власне визначення відображення або API клієнта. Експертна група JPA зібрала найкраще з усіх цих інструментів, і тому вони створили стандарт API Java Persistent API.

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

Стандартний JPA висунув конкуренцію Java ORM на новий рівень, і це може призвести лише до кращої реалізації.

Як пояснено в моїй книзі, Високопродуктивна Java-наполегливість , Hibernate пропонує функції, які ще не підтримуються JPA :

• генератори розширених ідентифікаторів ( привіт / ло , об'єднаний, об'єднаний-ло )
• прозора підготовка заявки
• настроюється CRUD ( @SQLInsert, @SQLUpdate, @SQLDelete) звітності
• статичні або динамічні колекції фільтрів (наприклад @FilterDef, @Filter, @Where) і об'єктні фільтри (наприклад @Where)
• відображення властивостей відображення фрагментів SQL (наприклад @Formula)
• незмінні утворення (наприклад @Immutable)
• більше режимів потоку (наприклад FlushMode.MANUAL, FlushMode.ALWAYS)
• запит кеша другого рівня природним ключем даної сутності
• стратегії одночасного кеш-пам'яті кешу (наприклад Cache(usage = CacheConcurrencyStrategy.READ_WRITE))
• версійні масові оновлення через HQL
• виключити поля з оптимістичної перевірки блокування (наприклад @OptimisticLock(excluded = true))
• оптимістичне блокування без версій (наприклад OptimisticLockType.ALL, OptimisticLockType.DIRTY)
• підтримка пропускання (не чекаючи) песимістичних запитів блокування
• підтримка Java 8 Дата і час
• підтримка багатостороннього життя
• підтримка м'якого видалення (наприклад @Where, @Filter)

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

З Вікі .

Мотивація для створення API Java Persistence

Багато корпоративних розробників Java використовують легкі стійкі об’єкти, що надаються рамками з відкритим кодом або об'єктами доступу до даних, а не об'єктивними бобами: суб'єкти бобів та боби підприємств мають репутацію надто важкої та складної, і їх можна було використовувати лише на серверах додатків Java EE. Багато функцій сторонніх систем стійкості були включені в API Java Persistence, а на 2006 рік такі проекти, як Hibernate (версія 3.2) та Open Source Source TopLink Essentials стали реалізацією API Java Persistence.

Як сказано на сторінці JCP, посилання Eclipse - це Референтна реалізація для JPA. Подивіться на цю відповідь, щоб дізнатися більше про це.

У самому JPA є функції, які дозволять скласти стандартну основу ORM. Оскільки JPA є частиною специфікації Java EE, ви можете використовувати JPA самостійно в проекті, і він повинен працювати з будь-якими серверами, сумісними з Java EE . Так, ці сервери матимуть реалізацію для специфікації JPA.

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

JPA - лише специфікація, яка потребує конкретної реалізації. За замовчуванням реалізація Oracle тепер є "Eclipselink". (Toplink пожертвує Oracle фонду Eclipse для об'єднання з eclipselink)

(Довідка: http://www.oracle.com/technetwork/middleware/toplink/index-085257.html http://www.eclipse.org/org/press-release/20080317_Eclipselink.php )

Використовуючи Eclipselink, можна бути впевненим, що код є переносним для будь-якої реалізації, якщо виникає потреба. Hibernate - це також повна реалізація JPA + БІЛЬШЕ (сортування JPA Plus). Hibernate - це супер набір JPA з деякою додатковою функцією сплячого режиму. Тому додаток, розроблений в режимі глибокого сну, може бути не сумісний при переході на іншу реалізацію. Досі сплячий режим - це вибір більшості розробників як реалізація JPA та широко використовується.

Інша реалізація JPA - OpenJPA (openjpa.apache.org), яка є розширенням реалізації Kodo.

JPA: подібно до інтерфейсу і не має конкретної реалізації для використання функцій, які є в JPA.

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

ПОРАДА: ви можете використовувати

     *combo 1* : JPA + JPA Provider(Hibernate) 
     *combo 2* : only Hiberante which does not need any interface 

Комбо 1 : застосовується тоді, коли ви відчуваєте, що ваш сплячий режим не дає кращих показників, і хочете змінити постачальника JPA, щоб у той час вам не доведеться писати свій JPA ще раз. Ви можете написати іншого постачальника послуг JPA ... і можете змінити стільки разів, скільки зможете.

Комбо 2 : використовується дуже рідше, оскільки коли ви не збираєтесь змінювати свого постачальника JPA будь-якою ціною.

Завітайте на сторінку http://blog-tothought.rhcloud.com//post/2 , де ваша повна розгубленість проясниться.

JPA - це інтерфейс, Hibernate - це одна з реалізацій цього інтерфейсу.

JPA - специфікація для стандартизації ORM-API. Hibernate - постачальник реалізації програми JPA. Отже, якщо ви використовуєте JPA зі сплячим режимом, ви можете використовувати стандартний API JPA, сплячка буде під кришкою, пропонуючи ще кілька нестандартних функцій. Див. Http://docs.jboss.org/hibernate/stable/entitymanager/reference/en/html_single/ та http://docs.jboss.org/hibernate/stable/annotations/reference/en/html_single/

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

Якщо ви використовуєте Hibernate або будь-якого іншого постачальника замість JPA, ви не можете легко перейти в сплячку до EclipseLink або OpenJPA до Hibernate. Але якщо ви використовуєте JPA, то вам просто потрібно змінити, надайте постійний XML-файл. Тому міграція легко можлива в JPA

JPA - це API, який реалізує Hibernate.Hibernate передує JPA. Перед JPA ви пишете нативний сплячий код, щоб зробити свою ORM. JPA - це лише інтерфейс, тому тепер ви пишете JPA-код і вам потрібно знайти реалізацію. Спячий стан є реалізацією.

Тож ваш вибір такий: сплячка, топова посилання тощо ...

Перевага JPA полягає в тому, що він дозволяє замінити свою реалізацію за потреби. Недоліком є ​​те, що вроджений API hibernate / toplink / тощо ... може запропонувати функціональні можливості, які специфікація JPA не підтримує.

Хоча JPA є специфікацією, Hibernate - це постачальник впровадження, який дотримується правил, продиктованих у специфікації.

Java - її незалежність не тільки від операційної системи, але і від постачальника.

Тому ви повинні мати змогу розгорнути свою програму на різних серверах прикладних програм. JPA реалізований на будь-якому сервері додатків, сумісних з Java EE, і дозволяє обмінятися серверами прикладних програм, але потім реалізація також змінюється. Програму Hibernate може бути простіше розгорнути на іншому сервері додатків.

JPA - це специфікація, яку ви реалізуєте у вашому рівні даних для виконання операцій db, АБО зіставлення та інших необхідних завдань.

Оскільки це лише специфікація , для її реалізації потрібен інструмент. Цей інструмент може бути як Hibernate, TopLink, iBatis, Spring-data тощо.

Вам не обов'язково потрібно JPA, якщо ви використовуєте сплячий режим у своєму шарі даних. Але якщо ви використовуєте специфікацію JPA для Hibernate, то це в майбутньому полегшить перехід на інші засоби ORM, такі як iBatis, TopLink, оскільки специфікація є загальною і для інших.

* ( якщо ви пам'ятаєте, ви робите, import javax.persistence.*;коли ви використовуєте примітки для відображення АБО (наприклад, @Id, @Column, @GeneratedValue тощо) у режимі глибокого сну, саме там ви використовуєте JPA в режимі Hibernate, ви можете використовувати @Query та інші функції JPA як добре )

JPA - специфікація Java API, яка описує управління реляційними даними в додатках, що використовують платформу Java. де як Hibernate - це бібліотека ORM (Object Relational Mapping), яка відповідає специфікації JPA.

Ви можете розглядати JPA як набір Правил, які реалізує Hibernate.

JPA - JSR, тобто вимога специфікації Java для впровадження Об'єктної реляційної карти, яка не має конкретного коду для її реалізації. Він визначає певний набір правил доступу, зберігання та управління даними між об'єктами Java та реляційною базою даних. З його введенням EJB було замінено, оскільки його спільнота розробників Java зазнала важкої ваги. Hibernate - це один із способів впровадження JPA за допомогою керівних принципів. Hibernate - це високоефективна послуга об'єктів / реляційності та запитів, яка ліцензується на основі ліцензії на загальну публічну ліцензію з відкритим кодом GNU (LGPL). Перевагою цього є те, що ви може замінити реалізацію JPA Hibernate на іншу реалізацію специфікації JPA.

JPA - лише специфікація, яка потребує конкретної реалізації. Типова реалізація, що надається Oracle, зараз є "Eclipselink". Toplink пожертвує Oracle фонду Eclipse для об'єднання з eclipselink.

Використовуючи Eclipselink, можна бути впевненим, що код є переносним для будь-якої реалізації, якщо виникає потреба. Hibernate - це також повна реалізація JPA + БІЛЬШЕ. Hibernate - це супер набір JPA з деякою додатковою функцією сплячого режиму. Таким чином, програма, розроблена в режимі глибокого сну, може не бути сумісною при переході на іншу реалізацію. Досі сплячий режим - це вибір більшості розробників як реалізація JPA та широко використовується.

Ще одна реалізація JPA - OpenJPA, яка є розширенням реалізації Kodo.

JPA vs Hibernate

Я намагаюся пояснити дуже легкими словами.

Припустимо, вам потрібен автомобіль, як ми всі знаємо їх кілька виробників A класу, як MERCEDES, BMW, AUDI тощо.

Тепер у вищезазначеному твердженні CAR (це специфікація), оскільки кожен автомобіль має спільні риси, як річ з 4 колесами і може бути загнаний по дорозі - це автомобіль ... так це як JPA. І MERCEDES, BMW, AUDI тощо просто використовують загальну характеристику автомобіля та додають функціональність відповідно до клієнтської бази, тому вони реалізують специфікацію автомобіля, наприклад, у сплячому режимі, iBATIS тощо.

Таким чином, ця загальна особливість переходить до jpa, а сплячий режим - це лише реалізація відповідно до їх потреб jboss.

Ще 1 річ

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

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

Дякую

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

API JPA або Java Persistence - це стандартна специфікація для реалізації ORM, тоді як Hibernate - це фактична реалізація ORM.

JPA - API персистентності Java. Який Вказує лише специфікації для API. Це означає, що набір правил та вказівок для створення API. Якщо говорить інший контекст, це набір стандартів, який забезпечує обгортку для створення цих API, може бути використаний для доступу об'єкта об'єкта з бази даних. JPA надається Oracle. Коли ми будемо робити доступ до бази даних, нам, безумовно, потрібна його реалізація. Значить JPA визначає лише вказівки щодо впровадження API. Hibernate - постачальник / постачальник JPA, який відповідає за впровадження цих API. Як Hibernate TopLink і Open JPA - це деякі приклади постачальників API JPA. Таким чином, ми використовуємо стандартні API API, визначені JPA, у сплячому режимі.

Образно кажучи, JPA - це просто інтерфейс, Hibernate / TopLink - клас (тобто реалізація інтерфейсу).

Для використання інтерфейсу ви повинні мати реалізацію інтерфейсу. Але ви можете використовувати клас через інтерфейс, тобто використовувати Hibernate через JPA API, або ви можете використовувати реалізацію безпосередньо, тобто використовувати Hibernate безпосередньо, а не через чистий JPA API.

Хороша книга про JPA - це "Високопродуктивна наполегливість Java" Влада Міхалчея.