Яка різниця між сплячим режимом сплячки та весняними даними

Які основні відмінності між сплячим режимом сплячки та Spring Data JPA? Коли ми не повинні використовувати сплячий або Spring Data JPA? Крім того, коли шаблон Spring JDBC може працювати краще, ніж JPA Hibernate / Spring Data?

Hibernate - це реалізація JPA, тоді як Spring Data JPA - абстракція доступу до даних JPA. Spring Data JPA не може працювати без постачальника JPA.

Spring Data пропонує рішення для шаблону DDDRepository або застарілих GenericDaoкористувацьких реалізацій. Він також може генерувати JPA-запити від вашого імені за допомогою назв методу.

За допомогою даних Spring ви можете використовувати сплячку, Eclipse Link або будь-якого іншого постачальника послуг JPA. Дуже цікавою перевагою використання Spring або Java EE є те, що ви можете декларативно керувати межами транзакцій, використовуючи @Transactionalпримітку .

Spring JDBC набагато легший, і він призначений для власного запиту, і якщо ви лише маєте намір використовувати JDBC в поодинці, то вам краще використовувати Spring JDBC для розгляду багатослівності JDBC.

Тому дані про сплячку та весну доповнюють, а не конкуренти.

Тут ми використовуємо 3 різні речі:

1. JPA: API стійкості Java, який надає специфікацію для збереження, зчитування, управління даними з вашого об'єкта Java до відносин у базі даних.
2. Спячий режим: Є різні постачальники, які реалізують jpa. Зимова сплячка - одна з них. Тож у нас є й інший провайдер. Але якщо використовувати jpa з весною, це дозволяє вам в майбутньому перейти до різних провайдерів.
3. Весняні дані JPA: Це ще один шар поверх jpa, який забезпечує весна, щоб полегшити ваше життя.

Тож давайте зрозуміємо, як працюють весняні дані jpa та spring + в сплячку-

Весняні дані JPA:

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

Тепер весняні дані jpa дозволяють нам визначити інтерфейси дао, розширивши його сховища (crudrepository, jparepository), щоб вони забезпечили вам реалізацію дао під час виконання. Вам більше не потрібно писати реалізацію дао. Це те, як весняні дані jpa полегшують ваше життя.

Я не погоджуюсь, що SpringJPA робить життя легко. Так, він пропонує деякі заняття, і ви можете зробити простий DAO швидко, але насправді це все, що ви можете зробити. Якщо ви хочете зробити щось більше, ніж findById () або зберегти, ви повинні пройти пекло:

• немає доступу EntityManager у класах org.springframework.data.repository (це базовий клас JPA!)
• власне управління транзакціями (сплячі операції заборонені)
• величезні проблеми з більш ніж однією конфігурацією джерел даних
• відсутність об'єднання джерел даних (HikariCP повинен використовуватися як стороння бібліотека)

Чому власне управління транзакціями є недоліком? Оскільки Java 1.8 дозволяє використовувати інтерфейси методів за замовчуванням, транзакції на основі весняних анотацій, прості не працюють.

На жаль, SpringJPA заснований на роздумах, і іноді потрібно вказати ім'я методу чи пакет сутності в анотації (!). Ось чому будь-який рефакторинг робить великі збої. На жаль, @Transactional працює лише для основного DS :( Отже, якщо у вас є більше одного DataSources, пам’ятайте - транзакції працюють лише для первинного :)

Які основні відмінності між сплячим режимом сплячки та Spring Data JPA?

Hibernate - сумісний з JPA, сумісний з SpringJPA Spring. Ваш HibernateJPA DAO можна використовувати з JavaEE або Hibernate Standalone, коли SpringJPA можна використовувати, наприклад, у Spring - SpringBoot

Коли ми не повинні використовувати сплячий або Spring Data JPA? Крім того, коли шаблон Spring JDBC може працювати краще, ніж JPA Hibernate / Spring Data?

Використовуйте Spring JDBC тільки тоді, коли вам потрібно використовувати багато приєднань або коли вам потрібно використовувати Spring з кількома підключеннями до джерела даних. Як правило, уникайте JPA для приєднання.

Але моя загальна порада, використовуйте свіжий розчин - Daobab ( http://www.daobab.io ). Daobab - це моя Java та будь-який інтегратор двигунів JPA, і я вважаю, що це допоможе багато у ваших завданнях :)

Spring Data- це бібліотека зручностей, JPAщо дозволяє абстрагувати багато речей і приносить магію весни (подобається вона чи ні) до доступу до магазину. В основному використовується для роботи з реляційними базами даних. Коротше кажучи, це дозволяє оголосити інтерфейси, які мають такі методи, findByNameOrderByAge(String name);які будуть проаналізовані під час виконання та перетворені у відповідні JPAзапити.

Його розміщення вгорі JPAробить його спокусливим для:

1. Новички-розробники, які не знають SQLабо погано знають це. Це рецепт катастрофи, але вони можуть уникнути цього, якщо проект є банальним.

2. Досвідчені інженери, які знають, чим займаються, і хочуть швидко розкручувати речі. Це може бути життєздатною стратегією (але читайте далі).

З мого досвіду Spring Data, її магія занадто велика (це стосується іSpring загалом). Я почав активно використовувати його в одному проекті і врешті-решт потрапив у декілька кутових випадків, коли я не міг вийти з бібліотеки і закінчився некрасивими способами вирішення проблем. Пізніше я прочитав скарги інших користувачів і зрозумів, що ці питання типові Spring Data. Наприклад, перевірте це питання, що призвело до годин розслідування / присяги:

 public TourAccommodationRate createTourAccommodationRate(
        @RequestBody TourAccommodationRate tourAccommodationRate
    ) {
        if (tourAccommodationRate.getId() != null) {
            throw new BadRequestException("id MUST NOT be specified in a body during entry creation");
        }

        // This is an ugly hack required for the Room slim model to work. The problem stems from the fact that
        // when we send a child entity having the many-to-many (M:N) relation to the containing entity, its
        // information is not fetched. As a result, we get NPEs when trying to access all but its Id in the
        // code creating the corresponding slim model. By detaching the entity from the persistence context we
        // force the ORM to re-fetch it from the database instead of taking it from the cache

        tourAccommodationRateRepository.save(tourAccommodationRate);
        entityManager.detach(tourAccommodationRate);
        return tourAccommodationRateRepository.findOne(tourAccommodationRate.getId());
    }

Я закінчився нижчим рівнем і почав користуватися JDBI- приємною бібліотекою з просто достатньою "магією", щоб врятувати вас від котла. З ним ви маєте повний контроль над запитами SQL і майже ніколи не доводиться боротися з бібліотекою.

Hibernate - це реалізація "JPA", яка є специфікацією для об'єктів Java в базі даних.

Я рекомендую використовувати wrt JPA, оскільки ви можете перемикатися між різними ORMS.

Коли ви використовуєте JDBC, тоді вам потрібно використовувати SQL запити, тому якщо ви знаєте SQL, тоді перейдіть до JDBC.

Якщо ви віддаєте перевагу простоті та більшому контролю над запитами SQL, то я б запропонував перейти з Spring Data / Spring JDBC.

Його хороший обсяг навчання в JPA, а іноді і важко налагодити проблеми. З іншого боку, хоча ви маєте повний контроль над SQL, оптимізувати запити та підвищити продуктивність стає набагато простіше. Ви можете легко поділитися своїм SQL з DBA або тим, хто краще розуміє Базу даних.