JPA чи JDBC, чим вони відрізняються?


119

Я вивчаю Java EE, і я завантажив затемнення зі скляною рибкою для того ж. Я бачив кілька прикладів, а також читав документи Oracle, щоб знати все про Java EE 5. Підключення до бази даних було дуже простим. Я відкрив динамічний веб-проект, створив сеанс EJB, використовував EntityManager і за допомогою методів get мав доступ до збереженої таблиці даних.

Для свого наступного проекту я повинен був створити простий клас, а потім отримати доступ до якоїсь таблиці БД. Перша проблема, з якою я зіткнулася, полягала в тому, що атрибут PersistenceUnit буде розпізнаний лише EJB, Servlet тощо, а не простий клас java. Тож я не міг використовувати спосіб EntityManager (чи можу я?)

Мене попросили пройти шляхом "JDBC". Найперша проблема, з якою я зіткнулася, - це з'єднання з БД. Здається, все це повинно бути жорстко закодовано. У мене був persistent.xml, за допомогою якого я міг легко налаштувати з'єднання бази даних. Навіть налаштування драйвера для БД було легко. Також у JDBC немає методів get / set для доступу до об'єктів таблиці.

Як я розумію JPA та наполегливість стосовно JDBC? Про що думав JPA? Чому існують методи встановлення / отримання? Може хтось кине трохи світла на суть цих двох і які плюси / мінуси без "жаргонів" ?? Просимо також запропонувати декілька посилань. Простий пошук Google в розрізненнях JPA та JDBC привів мене до деяких сайтів, наповнених "термінологією", яку я не міг дотримуватися :(


2
Чому б не почати з підручника JDBC: docs.oracle.com/javase/tutorial/jdbc/index.html
a_horse_with_no_name

2
JPA можна використовувати без EJB або навіть Java EE, ви можете створити EntityManagerFactory безпосередньо з Persistence.
Джеймс

Відповіді:


237

Простіше кажучи:

  • JDBC - стандарт для доступу до бази даних
  • JPA - стандарт для ORM

JDBC є стандартом для підключення до БД безпосередньо і працює SQL проти нього - наприклад , SELECT * FROM USERSі т.д. набори даних можуть бути повернуті , які ви можете обробляти в вашому додатку, і ви можете робити все звичайні речі , як INSERT, DELETE, запускати збережені процедури і т.д. Це одна з основних технологій, що лежить в основі більшості доступу до бази даних Java (включаючи провайдерів JPA).

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

JPA - стандарт для об'єктивного реляційного картографування. Це технологія, яка дозволяє відображати об’єкти в кодах і таблицях баз даних. Це може "приховати" SQL від розробника, так що всі вони мають справу з класами Java, а провайдер дозволяє зберегти їх і магічно завантажити. Здебільшого, XML-файли відображення чи анотації на геттерах і сеттерах можна використовувати, щоб повідомити постачальнику JPA, які поля на вашій карті об’єкта, які поля в БД. Найвідоміший постачальник JPA - Hibernate , тому це хороше місце для початку конкретних прикладів.

Інші приклади включають OpenJPA, toplink тощо.

Під кришкою, Hibernate та більшість інших постачальників для JPA пишуть SQL та використовують JDBC для читання та запису з та в БД.


3
iBatis (нині MyBatis) не є реалізацією JPA. Якщо ви поглянете на це, ви помітите, що він має зовсім іншу концепцію.
Мікко Мауну

Дякую! Моя помилка, я вважав, що вона реалізує JPA, виправлена ​​зараз!
Марк D

3
Не всі постачальники JPA пишуть SQL та використовують JDBC ... оскільки вони можуть зберігатись у "різному типі сховищ даних" (MongoDB, Neo4j тощо). DataNucleus JPA є одним з таких прикладів
DataNucleus

правдивий DataNucleus .. Є навіть ті, що є для excel тощо - оригінальні запитання були JDBC / JPA, тому я правильно чи неправильно припускав, що він цікавиться реляційними магазинами.
Марк D

52

Основна відмінність JPA від JDBC - рівень абстракції.

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


20

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

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


10

JDBC є попередником JPA.

JDBC - це міст між світом Java та світом баз даних. У JDBC вам потрібно викрити всі брудні деталі, необхідні для операцій CRUD, такі як назви таблиць, назви стовпців, тоді як у JPA (який використовується JDBC під ним) ви також вказуєте ці деталі метаданих бази даних, але з використанням анотацій Java.

Таким чином, JPA створює запити оновлення для вас та керує особами, які ви шукали чи створювали / оновлювали (це також більше).

Якщо ви хочете зробити JPA без контейнера Java EE, тоді Spring та його бібліотеки можуть використовуватися з тими самими анотаціями на Java.


"без контейнера Java EE ??" Ви маєте на увазі, що Spring та її бібліотеки не залежать від веб-контейнера?
Брюс Зу

@BruceZu Звичайно, це так. Ви можете використовувати багато компонентів Spring Framework без необхідності веб-контейнера. Наприклад, введення залежностей - це не те, що потрібно лише у веб-контексті.
Дольфіз

1
@Dolfiz - чи не весняні веб-бібліотеки є обгорткою над бібліотеками Java Web та Java EE?
raikumardipak
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.