JPA veya JDBC, nasıl farklılar?


119

Java EE öğreniyorum ve aynısı için cam balığı ile tutulmayı indirdim. Bazı örnekler gördüm ve ayrıca Java EE 5 hakkında her şeyi öğrenmek için Oracle belgelerini okudum. Bir veritabanına bağlanmak çok basitti. Dinamik bir web projesi açtım, oturum EJB oluşturdum, EntityManager'ı kullandım ve get yöntemleriyle depolanan veri tablosuna erişebildim.

Bir sonraki projem için basit bir sınıf oluşturup bazı DB tablolarına eriştim. Karşılaştığım ilk sorun, PersistenceUnit özniteliğinin basit bir java sınıfı değil, yalnızca EJB, Servlet vb. Tarafından tanınmasıydı. O halde EntityManager yolunu kullanamadım (veya kullanabilir miyim?)

"JDBC" yolundan gitmem istendi. Karşılaştığım ilk sorun, DB ile bağlantı kurmaktı. Görünüşe göre tüm bunlar kodlanmış olmalı. Veri tabanı bağlantısını kolayca yapılandırabileceğim bir persistence.xml'im vardı. DB için bir sürücü kurmak bile kolaydı. Ayrıca, JDBC'de tablo varlıklarına erişmek için alma / ayarlama yöntemi yoktur.

JPA'yı ve JDBC ile ilgili kalıcılığı nasıl anlarım? JPA ne düşündü? Ayarlama / alma yöntemleri neden var? Birisi bu ikisinin özüne biraz ışık tutabilir mi ve "jargon" olmadan artıları / eksileri nelerdir? Lütfen ayrıca bazı bağlantılar önerin. JPA ve JDBC farklılıkları için basit bir Google araması beni takip edemediğim "terminoloji" ile dolu bazı sitelere yönlendirdi :(


2
Neden JDBC öğreticisiyle başlamıyorsunuz
a_horse_with_no_name

2
JPA, EJB veya hatta Java EE olmadan kullanılabilir, doğrudan Persistence'dan bir EntityManagerFactory oluşturabilirsiniz.
James

Yanıtlar:


238

Layman'ın terimleriyle:

  • JDBC, Veritabanı Erişimi için bir standarttır
  • JPA, ORM için bir standarttır

Örneğin - JDBC doğrudan DB bağlanma ve buna karşı SQL çalıştırmak için bir standarttır SELECT * FROM USERS, Veri kümeleri uygulamasında işleyebilir ve tüm olağan şeyler yapabilirsiniz hangi iade edilebilir vs. gibi INSERT, DELETEçalıştırmak saklı prosedürler, vs. Çoğu Java veritabanı erişiminin (JPA sağlayıcıları dahil) arkasındaki temel teknolojilerden biridir.

Geleneksel JDBC uygulamalarıyla ilgili sorunlardan biri, veri kümeleri ve nesneler arasında çok sayıda eşlemenin gerçekleştiği, mantığın SQL ile karıştırıldığı vb. Berbat kodlara sahip olabilmenizdir.

JPA, Nesne İlişkisel Haritalama için bir standarttır. Bu, kod ve veritabanı tablolarındaki nesneler arasında eşleme yapmanızı sağlayan bir teknolojidir. Bu, SQL'i geliştiriciden "gizleyebilir", böylece tüm ilgilendikleri şey Java sınıfları olur ve sağlayıcı bunları kaydetmenize ve sihirli bir şekilde yüklemenize izin verir. Çoğunlukla, alıcılar ve ayarlayıcılar üzerindeki XML eşleme dosyaları veya ek açıklamalar, JPA sağlayıcınıza nesne üzerindeki hangi alanların DB'deki hangi alanlarla eşleştiğini söylemek için kullanılabilir. En ünlü JPA sağlayıcısı Hibernate'dir , bu nedenle somut örnekler için başlamak için iyi bir yerdir.

Diğer örnekler arasında OpenJPA, toplink vb.

Temel olarak, Hibernate ve diğer birçok JPA sağlayıcısı SQL yazar ve DB'den okumak ve DB'ye yazmak için JDBC kullanır.


3
iBatis (günümüzde MyBatis) bir JPA uygulaması değildir. Ona bir bakarsanız, konseptinin çok farklı olduğunu fark edeceksiniz.
Mikko Maunu

Teşekkürler! Hatam, JPA uyguladığını sanıyordum, şimdi düzeltildi!
Mark D

3
Tüm JPA sağlayıcıları SQL yazmaz ve JDBC kullanmaz ... çünkü bunlar "farklı türde bir veri deposunda" (MongoDB, Neo4j, vb.) Kalabilirler. DataNucleus JPA böyle bir örnektir
DataNucleus

doğru DataNucleus .. excel için olanlar bile var, vs - asıl sorular JDBC / JPA idi, bu yüzden doğru veya yanlış olarak ilişkisel mağazalarla ilgilendiğini varsaydım.
Mark D

52

JPA ve JDBC arasındaki temel fark, soyutlama seviyesidir.

JDBC, veritabanları ile etkileşim için düşük seviyeli bir standarttır. JPA aynı amaç için daha yüksek seviyeli bir standarttır. JPA, uygulamanızda hayatınızı çok daha kolay hale getirebilecek bir nesne modeli kullanmanızı sağlar. JDBC, Veritabanı ile doğrudan daha fazla şey yapmanıza izin verir, ancak daha fazla dikkat gerektirir. Bazı görevler JPA kullanılarak verimli bir şekilde çözülemez, ancak JDBC ile daha verimli bir şekilde çözülebilir.


20

JDBC, JPA'dan çok daha düşük seviyeli (ve daha eski) bir belirtimdir. Temel özellikleriyle JDBC, salt SQL kullanarak bir veritabanıyla etkileşim kurmak için bir API'dir - sorgu gönderme ve sonuçları alma. Nesne veya hiyerarşi kavramı yoktur. JDBC'yi kullanırken, bir sonuç kümesini (esasen SQL sorgunuz tarafından döndürülen bir veya daha fazla veritabanı tablosundan değerlerin satır / sütun matrisi) Java nesnelerine çevirmek size kalmıştır.

Şimdi, JDBC'yi anlamak ve kullanmak için SQL hakkında biraz anlayış ve çalışma bilgisine sahip olmanız çok önemlidir. Bununla birlikte, ilişkisel bir veritabanının ne olduğu, onunla nasıl çalıştığınız ve tablolar, sütunlar, anahtarlar ve ilişkiler gibi kavramlar hakkında gerekli bir içgörü de gelir. Veritabanları, SQL ve veri modelleme hakkında en azından temel bir anlayışa sahip olmadığınız sürece, JDBC'den fazla yararlanamayacaksınız çünkü bu, aslında bunların üzerinde sadece ince bir soyutlamadır.


10

JDBC, JPA'nın öncülüdür.

JDBC, Java dünyası ile veritabanları dünyası arasında bir köprüdür. JDBC'de, tablo adları, sütun adları gibi CRUD işlemleri için gereken tüm kirli ayrıntıları ifşa etmeniz gerekirken, JPA'da (altında JDBC kullanılıyor), veritabanı meta verilerinin bu ayrıntılarını, ancak Java notlarını kullanarak da belirtirsiniz.

Dolayısıyla, JPA sizin için güncelleme sorguları oluşturur ve aradığınız veya oluşturduğunuz / güncellediğiniz varlıkları yönetir (daha fazlasını da yapar).

Java EE kabı olmadan JPA yapmak istiyorsanız, Spring ve kütüphaneleri aynı Java notlarıyla kullanılabilir.


"Java EE kapsayıcısı olmadan ??" Spring ve kütüphanelerinin web kapsayıcısından bağımsız olduğunu mu söylüyorsunuz?
Bruce Zu

@BruceZu Tabii ki öyle. Spring çerçeve bileşenlerinin birçoğunu bir web kabına ihtiyaç duymadan kullanabilirsiniz. Örneğin, bağımlılık ekleme, yalnızca web bağlamında ihtiyacınız olan bir şey değildir.
Dolfiz

1
@Dolfiz, ilkbahar web kitaplıkları Java Web ve Java EE kitaplıkları üzerinde bir sarmalayıcı değil mi?
raikumardipak
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.