Для нового проекту JPA завжди є рекомендованим інструментом для обробки реляційних даних або існують сценарії, коли Spring JdbcTemplate є кращим вибором? Деякі фактори, які слід врахувати у своїй відповіді:
Відповіді:
Використовуйте Spring JdbcTemplate, якщо ви не хочете отримувати доступ до схеми бази даних через модель домену. Використовуючи JdbcTemplate, ви використовуєте доступ нижчого рівня, з більшою гнучкістю, але, ймовірно, також більшою кількістю зразків.
Spring JdbcTemplate можна легше використовувати з екзотичними схемами баз даних та фокусом збережених процедур. Використовуючи JPA, потрібно переконатися, що схема бази даних правильно відображається у моделі домену.
Обидві технології потребують розробників, які знають реляційні бази даних, SQL та транзакції. Завдяки JPA ви отримуєте більше прихованої складності.
Наскільки мені відомо, JPA легше підключається до шарів кешування даних, оскільки об’єктно-орієнтоване фокус полегшує ідентифікацію, оновлення та анулювання записів кешу.
Ви можете краще налаштувати бекенди на основі JdbcTemplate, але в більшості випадків задіяно більше коду.
Деякий інший аспект, який слід врахувати, полягає в тому, що, хоча з JPA ви отримуєте модель домену для вашої схеми бази даних, вам часто доведеться використовувати додаткові класи DTO. Використовуючи JdbcTemplate, ви можете безпосередньо працювати з класами DTO.
Я трохи запізнився з цим повідомленням, але я, як правило, використовую JdbcTemplate над ORM. Я знаю SQL (досить добре) і справді не хочу "абстрагуватися" від моєї БД. Я вважаю, що більшість часу мої програми використовують подання БД, де я підштовхую більшість бізнес-логіки. Я правильно наклав DAO, які мають реалізації JdbcTemplate. Він відчуває себе "чистим", і більшість зразкових кодів приховано JdbcTemplate (і його онлайн-документація здається НАБАГАТО кращою, ніж речі ORM). Обмежений час, коли я користувався чимось на кшталт Hibernate, я виявив, коли він спрацював, це заощадило мені час ... але коли він не працював належним чином, це коштувало мені днів налагодження "WTF". Мені ніколи не доводилося витрачати більше 20 хвилин на налагодження імпульсів JdbcTemplate DAO. Я думаю, що ключовим фактором, як зазначали інші, є те, наскільки вам комфортно користуватися SQL / Schema Design
Я згоден з @Timo. Єдине інше розуміння, яке я хотів би додати / розширити, - це те, що ORM має іншу семантику від чистого доступу до sql до ваших даних.
Суть ORM полягає в тому, щоб максимально абстрагувати той факт, що ваші дані взагалі знаходяться в БД. Коли ви використовуєте ORM належним чином, усі операції персистенції виконуються в один (сподіваємось) тонкий шар. Об'єкти вашої моделі матимуть мало або взагалі не матимуть коду стійкості; той факт, що ви використовуєте ORM, повинен бути невидимим для вашої моделі.
Завдяки цьому ORM дуже добре полегшує вам життя для певних типів операцій, а саме простих CRUD-операцій. Ви можете завантажувати свої об’єкти моделі, представляти їх, оновлювати, видаляти досить легко. Це полегшує вам життя, тому що коли ви отримуєте доступ до своїх даних, ви повертаєте об'єкти моделі, на яких ви можете писати ділову логіку. Якщо ви використовуєте JDBC, вам доведеться "гідратувати" екземпляри об'єктів з даних, які можуть бути складними та схильними до помилок.
ORM - не завжди найкращий вибір. JPA - це інструмент для роботи, якщо інструменту недостатньо для роботи, ви захочете знайти кращий інструмент. Наприклад, у мене був сценарій, коли мені довелося скопіювати весь графік об’єкта та зберегти нову копію цих об’єктів. Якщо я використовував ORM (як я намагався це зробити), мені довелося завантажити всі об'єкти з БД, скопіювати їх, а потім зберегти нові об'єкти. Я зайняв занадто багато часу.
Кращим рішенням було просто використовувати операції, засновані на jdbc, і "вставити через вибір" виклики sql для створення нових рядків. Це було швидко, код був простішим.
Інша річ, яку слід врахувати, це те, що вам комфортно з JDBC і у вас є терміни, вам не доведеться стрибати на перемогу ORM. Класи Spring JdbcTemplate надзвичайно потужні та корисні. Іноді найкращим інструментом для роботи є той, який ви знаєте. Вам слід ознайомитися з ORM, але не обов’язково для проекту з високими очікуваннями. Тут можна багато чому навчитися, і це не тривіально - насправді ви торгуєте одним набором складностей з іншим, вибираючи використовувати jdbc vs orm.
В інших відповідях це не згадується, але добре використовувати обидва. У своєму додатку я використовую JPA та JdbcTemplate, для сирих операцій я використовую JPA, але для звітування або там, де простіше, я використовую jdbcTemplate.
@Repository
public class FooRepository
{
@PersistenceContext
private EntityManager entityManager;
@Autowired(required = true)
private JdbcTemplate jdbcTemplate;
public void saveFoo(Foo foo)
{
this.entityManager.persist(foo);
}
public List<SomeReportPojo> getSomeReport()
{
return this.jdbcTemplate.queryForList("SELECT .. ",SomeProjectPojo.class);
}
}
Чудова річ у Spring полягає в тому, що переклад винятків із винятків JPA на ієрархію винятків Spring Dao працює як з JPA, так і з jdbcTemplate. Тому використовуйте JPA, коли це має сенс, і jdbcTemplate, коли це має сенс.
getSomeReport()бути this.jdbcTemplate. ...швидше ніж this.entityManager. ...?
На роботі ми використовуємо Hibernate JDBCTemplate, оскільки він має більшу гнучкість. Він також має кращу продуктивність, ніж JPA, оскільки ви не "завантажуєте" багато непотрібних даних у свій додаток.
У випадку JDBCTemplate ваші навички SQL значною мірою дають вам саме те, що вам потрібно, з потрібною швидкістю.