Hazırda Bekleme ve Bahar Verileri JPA arasındaki fark nedir

Hazırda Beklet ve İlkbahar Verileri JPA arasındaki temel farklar nelerdir? Hazırda Beklet veya Bahar Verileri JPA'yı ne zaman kullanmamalıyız? Ayrıca, Bahar JDBC şablonu Hazırda Bekletme / Yay Verisi JPA'dan daha iyi performans gösterebilir mi?

Hibernate bir JPA uygulaması, Spring Data JPA ise bir JPA veri erişim soyutlamasıdır. Spring Data JPA, JPA sağlayıcısı olmadan çalışamaz.

Spring Data, DDD Repositorymodeline veya eski GenericDaoözel uygulamalara bir çözüm sunar . Ayrıca yöntem adı kurallarıyla sizin adınıza JPA sorguları oluşturabilir.

Spring Data ile Hazırda Bekletme, Eclipse Link veya başka bir JPA sağlayıcı kullanabilirsiniz. Bahar veya Java EE kullanmanın çok ilginç yararı olduğunu bildirimli kullanarak işlem sınırlarını kontrol edebilirsiniz @Transactionalek açıklama .

Spring JDBC çok daha hafiftir ve yerel sorgulama için tasarlanmıştır ve yalnızca JDBC'yi tek başına kullanmayı düşünüyorsanız, JDBC ayrıntılarıyla başa çıkmak için Spring JDBC'yi kullanmaktan daha iyidir.

Bu nedenle, Hazırda Bekletme ve Bahar Verileri rakiplerden ziyade tamamlayıcıdır.

Burada kullandığımız 3 farklı şey var:

1. JPA: Java nesnenizden veritabanındaki ilişkilere kadar verilerin kalıcılığı, okunması, yönetilmesi için şartname sağlayan Java kalıcılık API'si.
2. Hazırda Bekletme: jpa uygulayan çeşitli sağlayıcılar vardır. Hazırda bekletme bunlardan biri. Yani başka sağlayıcılarımız da var. Ancak jpa'yı yay ile kullanıyorsanız, gelecekte farklı sağlayıcılara geçmenizi sağlar.
3. Bahar Verileri JPA: Baharın hayatınızı kolaylaştırmak için sağladığı jpa'nın üstünde başka bir katman.

Bahar verisi jpa ve spring + hibernate'in nasıl çalıştığını anlayalım.

Bahar Verileri JPA:

Diyelim ki uygulamanız için bahar + hazırda bekletme modunu kullanıyorsunuz. Şimdi, SessionFactory hibernate kullanarak crud işlemi yazacağınız dao arayüzüne ve uygulamasına ihtiyacınız var. Diyelim ki Çalışan sınıfı için dao sınıfı yazıyorsunuz, yarın başvurunuzda başka bir varlık için benzer crud operasyonu yazmanız gerekebilir. Burada görebileceğimiz çok sayıda kazan plakası kodu var.

Şimdi Bahar verileri jpa, depolarını (crudrepository, jparepository) genişleterek dao arayüzlerini tanımlamamıza izin verir, böylece çalışma zamanında dao uygulamasını sağlar. Artık dao uygulamasını yazmanıza gerek yok.Bu yüzden bahar verisi jpa hayatınızı kolaylaştırır.

SpringJPA'nın hayatı kolaylaştırdığını kabul etmiyorum. Evet, bazı sınıflar sağlar ve basit DAO'ları hızlı bir şekilde yapabilirsiniz, ancak aslında tüm yapabileceğiniz budur. FindById () 'den başka bir şey yapmak veya kaydetmek istiyorsanız, cehennemden geçmelisiniz:

• org.springframework.data.repository sınıflarında EntityManager erişimi yok (bu temel JPA sınıfıdır!)
• kendi işlem yönetimi (hazırda bekletme işlemlerine izin verilmiyor)
• birden fazla veri kaynağı yapılandırmasında büyük sorunlar
• veri kaynağı havuzu oluşturma (HikariCP üçüncü taraf kitaplığı olarak kullanılmalıdır)

Kendi işlem yönetimi neden bir dezavantajdır? Java 1.8, arayüzlere varsayılan yöntemlere izin verdiğinden, Bahar ek açıklama tabanlı işlemler, basit çalışmaz.

Ne yazık ki, SpringJPA yansımalara dayanır ve bazen bir yöntem adını veya varlık paketini ek açıklamalara (!) İşaret etmeniz gerekir. Bu yüzden herhangi bir yeniden düzenleme büyük bir çöküş yaratmaktadır. Ne yazık ki, @Transactional yalnızca birincil DS için çalışır :( Birden fazla DataSources varsa, unutmayın - işlemler yalnızca birincil DS için çalışır :)

Hazırda Beklet ve İlkbahar Verileri JPA arasındaki temel farklar nelerdir?

Hazırda bekletme JPA uyumlu, SpringJPA Bahar uyumludur. HibernateJPA DAO'nuz, SpringJPA Bahar içinde kullanılabildiğinde JavaEE veya Hibernate Standalone ile kullanılabilir - SpringBoot

Hazırda Beklet veya Bahar Verileri JPA'yı ne zaman kullanmamalıyız? Ayrıca, Bahar JDBC şablonu Hazırda Bekletme / Yay Verisi JPA'dan daha iyi performans gösterebilir mi?

Spring JDBC'yi yalnızca çok fazla Katılmanız gerektiğinde veya birden çok veri kaynağı bağlantısı olan Yay kullanmanız gerektiğinde kullanın. Genellikle, Katılma için JPA'dan kaçının.

Ama genel tavsiyem, taze bir çözüm kullanın - Daobab ( http://www.daobab.io ). Daobab benim Java'm ve herhangi bir JPA motor entegratörüdür ve görevlerinize çok yardımcı olacağına inanıyorum :)

Spring Dataüstündeki JPApek çok şeyi ortadan kaldıran ve devam eden mağaza erişimine Spring magic'i (beğen ya da beğenme) getiren bir kolaylık kütüphanesidir . Öncelikle ilişkisel veritabanlarıyla çalışmak için kullanılır. Kısacası, findByNameOrderByAge(String name);çalışma zamanında ayrıştırılacak ve uygun JPAsorgulara dönüştürülecek bunun gibi yöntemlere sahip arabirimler bildirmenize izin verir .

Bunun üzerine yerleştirilmesi JPA, kullanımının cazip olmasını sağlar:

1. SQLKötü bilmeyen veya bilmeyen çaylak geliştiriciler . Bu bir felaket tarifi ama proje önemsizse ondan kurtulabilirler.

2. Ne yaptıklarını bilen ve işleri hızlı bir şekilde hızlandırmak isteyen deneyimli mühendisler. Bu uygulanabilir bir strateji olabilir (ancak daha fazlasını okuyun).

Deneyimlerime göre Spring Data, büyüsü çok fazla (bu Springgenel olarak uygulanabilir ). Bir projede yoğun bir şekilde kullanmaya başladım ve sonunda kütüphaneyi yolumdan alamadığım ve çirkin geçici çözümlerle sonuçlandığım birkaç köşe vakasına çarptım. Daha sonra diğer kullanıcıların şikayetlerini okudum ve bu sorunların tipik olduğunu fark ettim Spring Data. Örneğin, saatlerce araştırma / küfür edilmesine neden olan bu sorunu kontrol edin:

 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());
    }

Daha düşük bir seviyeye çıktım ve kullanmaya başladım JDBI- sizi kazandan kurtarmak için yeterli "büyü" ile güzel bir kütüphane. Bununla birlikte, SQL sorguları üzerinde tam kontrole sahip olursunuz ve neredeyse hiçbir zaman kütüphaneyle savaşmak zorunda kalmazsınız.

Hazırda Beklet, Veritabanındaki Java nesneleri için bir özellik olan "JPA" nın uygulanmasıdır.

Farklı ORMS arasında geçiş yapabileceğiniz için wrt JPA kullanmanızı tavsiye ederim.

JDBC kullandığınızda, SQL Sorguları kullanmanız gerekir, bu nedenle SQL konusunda yetkinseniz JDBC için gidin.

SQL sorguları üzerinde basitlik ve daha fazla kontrol tercih ederseniz ben Spring Data / Spring JDBC ile devam öneririz.

JPA iyi öğrenme eğrisi miktarı ve bazen hata ayıklamak zor. Öte yandan, SQL üzerinde tam kontrole sahip olsanız da, sorguyu optimize etmek ve performansı artırmak çok daha kolay hale gelir. SQL'inizi DBA veya Veritabanını daha iyi anlayan biriyle kolayca paylaşabilirsiniz.