Hibernate vs JPA vs JDO - her birinin artıları ve eksileri? [kapalı]

ORM'i bir kavram olarak tanıyorum ve hatta birkaç yıl önce bir .NET projesi için nHibernate kullandım; ancak, Java'da ORM konusunu takip etmedim ve bu araçlardan herhangi birini kullanma şansım olmadı.

Ancak, şimdi bir dizi eski web hizmetinden uzaklaşmak için bazı ORM araçlarını uygulamalarımızdan biri için kullanmaya başlayabilirim.

JPA spesifikasyonları, Hibernate kütüphanesinin kendisi ile ne elde ettiğiniz ve JDO'nun neler sunabileceği arasındaki farkı anlatmakta zorlanıyorum.

Yani, bu sorunun biraz açık uçlu olduğunu anlıyorum, ancak şu konularda bazı görüşler almayı umuyordum:

• Her birinin artıları ve eksileri nelerdir?
• Yeni bir proje için hangisini önerirsiniz?
• Bir çerçeveyi diğerine karşı kullanmanın mantıklı olacağı belirli koşullar var mı?

Bazı notlar:

• JDO ve JPA, uygulama değil teknik özelliklerdir.
• Fikir, kodunuzu yalnızca standart JPA kullanmakla kısıtlarsanız JPA uygulamalarını değiştirebilirsiniz. (JDO için aynen.)
• Hazırda bekletme, bu tür bir JPA uygulaması olarak kullanılabilir.
• Bununla birlikte, Hibernate, JPA'nın üzerinde ve ötesinde özelliklere sahip yerel bir API sağlar.

IMO, Hibernate'i tavsiye ederim.

Hazırda Bekletme'ye özgü özellikleri kullanmanız gerekiyorsa ne yapmanız gerektiği hakkında bazı yorumlar / sorular var . Buna bakmanın birçok yolu var, ama benim tavsiyem:

• Tedarikçi bağlanma olasılığı konusunda endişelenmiyorsanız, Hazırda Bekletme ile karar verme sürecinde çeşitli satıcıya özgü uzantılar dahil olmak üzere diğer JPA ve JDO uygulamaları arasında seçiminizi yapın.

• Satıcının bağlanması olasılığından endişe duyuyorsanız ve satıcıya özgü uzantılara başvurmadan JPA kullanamıyorsanız, JPA kullanmayın. (JDO için aynen).

Gerçekte, muhtemelen trade-off gerekecektir ne kadar sen karşı tie-satıcı tarafından endişeli ne kadar o satıcı belirli uzantıları gerekir.

Ayrıca, sizin / personelinizin ilgili teknolojileri ne kadar iyi bildikleri, ürünlerin lisanslamada ne kadar tutacağı ve JDO ve JPA için gelecekte ne olacağına dair hikayesine inandığınız gibi başka faktörler de vardır.

JDO'nun DataNucleus uygulamasını değerlendirdiğinizden emin olun. Hibernate ile başladık, çünkü çok popüler görünüyordu, ancak çok yakında bunun% 100 şeffaf bir kalıcı çözüm olmadığı anlaşıldı. Çok fazla uyarı var ve belgeler, ancak bu duruma sahipseniz, istediğiniz gibi özgürce modelleme ve kodlama eğlencesini ortadan kaldıran kodunuzu bu şekilde yazmalısınız. JDO, kodumun veya modelimin 'düzgün çalışması' için ayarlamamı hiç sağlamadı . Basit POJO'ları sadece 'bellekte' kullanacakmışım gibi tasarlayabilir ve kodlayabilirim, ancak şeffaf bir şekilde devam edebilirim.

Hazırda bekletme modundaki JDO / DataNucleus'un diğer avantajı, çalışma zamanı yansıması yüküne sahip olmaması ve daha fazla bellek verimliliği sağlamasıdır, çünkü bunun yerine derleme zamanı bayt kodu geliştirmeyi kullanır (belki de büyük bir proje için derleme sürenize 1 sn ekleyin) hazırda bekletme modunun çalışma zamanı yansıması ile çalışan proxy kalıbından daha fazla.

Hibernate ile sinir bozucu bulabileceğiniz başka bir şey, nesne olduğunu düşündüğünüz bir referansın nesnedir ... genellikle nesne için bir 'proxy' dir. Bayt kodu geliştirmenin avantajı olmadan, isteğe bağlı yüklemeye izin vermek için proxy kalıbı gerekir (yani, bir üst düzey nesneyi çekerken tüm nesne grafiğinizi çekmekten kaçının). Eşitlediğinizi ve hashcode'u geçersiz kılmaya hazır olun çünkü başvurduğunuzi düşündüğünüz nesne genellikle bu nesne için bir proxy'dir.

Hibernate ile JDO ile elde edemeyeceğiniz hayal kırıklıklarına bir örnek:

http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53

'Geçici çözümlere' kodlamayı seviyorsanız, Hazırda Bekletme tam size göre. Modelleme, tasarım ve kodlamaya tüm zamanınızı harcadığınız temiz, saf, nesne odaklı, modele dayalı geliştirmeyi takdir ediyorsanız ve bunların hiçbirini çirkin geçici çözümlerde harcamayın, JDO / DataNucleus'u değerlendirmek için birkaç saat harcayın . Yatırım yapılan saatler bin kat geri ödenecek.

Güncelleme Şubat 2017

Uzun bir süredir DataNucleus, JDO kalıcılık standardına ek olarak JPA kalıcılık standardını uygulamaktadır, bu nedenle mevcut JPA projelerinin Hazırda Bekletme'den DataNucleus'a taşınması çok basit olmalıdır ve DataNucleus'un yukarıda belirtilen tüm avantajlarını çok az kod değişikliği ile elde edebilirsiniz. , varsa. Yani soru açısından, belirli bir standart, JPA (yalnızca RDBMS) ve JDO (RDBMS + Hayır SQL + ODBMSes + diğerleri) seçimi, DataNucleus her ikisini de destekler, Hazırda Beklet yalnızca JPA ile sınırlıdır.

Hazırda Bekletilen DB güncellemelerinin performansı

Bir ORM seçerken göz önünde bulundurulması gereken bir diğer konu, kirli kontrol mekanizmasının verimliliğidir - bu, mevcut işlemde değişen nesneleri güncellemek için SQL oluşturması gerektiğinde çok önemli hale gelir - özellikle çok fazla nesne olduğunda. Hibernate'in kirli kontrol mekanizmasının bu SO cevabında ayrıntılı bir teknik açıklaması var: HIBERNATE insertli JPA çok yavaş

Son zamanlarda bir java projesi için bir kalıcılık çerçevesi değerlendirip seçtim ve bulgularım aşağıdaki gibidir:

Ne görüyorum ki JDO lehine destek öncelikle:

• sql olmayan veri kaynakları, db4o, hbase, ldap, bigtable, couchdb (cassandra için eklentiler) vb.
• bir sql'den sql olmayan veri kaynağına veya tam tersine kolayca geçiş yapabilirsiniz.
• proxy nesnesi yok ve bu nedenle hashcode () ve equals () uygulamalarında daha az acı var
• daha fazla POJO ve dolayısıyla daha az geçici çözüm gerekir
• daha fazla ilişki ve alan türünü destekler

ve JPA lehine destek öncelikle:

• daha popüler
• jdo öldü
• bayt kodu geliştirme kullanmaz

JDO / Datanucleus'u JDO kullanmadığı için zayıf argümanlar sunan açıkça kullanmayan JPA geliştiricilerinden bir çok JPA yanlısı gönderi görüyorum.

JDO'ya geçiş yapan ve sonuç olarak çok daha mutlu olan JDO kullanıcılarından da birçok yayın görüyorum.

JPA'nın daha popüler olması açısından, bunun kısmen teknik olarak üstün olmaktan ziyade RDBMS satıcı desteğinden kaynaklandığı görülmektedir. (Bana VHS / Betamax gibi geliyor).

JDO ve referans uygulaması Datanucleus, Google'ın GAE'yi benimsemesi ve kaynak kodunda aktif geliştirme (http://sourceforge.net/projects/datanucleus/) tarafından gösterildiği gibi açıkça ölmedi.

Bayt kodu geliştirme nedeniyle JDO ile ilgili birtakım şikayetler gördüm, ancak neden kötü olduğu için henüz bir açıklama yok.

Aslında, NoSQL çözümleri tarafından giderek daha saplantı haline gelen bir dünyada, JDO (ve datanucleus uygulaması) çok daha güvenli bir bahis gibi görünüyor.

Ben sadece JDO / Datanucleus kullanmaya başladım ve db4o ve mysql arasında kolayca geçiş yapabilmeniz için ayarladım. Hızlı gelişim için db4o kullanmak ve DB şeması hakkında çok fazla endişelenmenize gerek kalmaz ve daha sonra, şema bir veritabanına dağıtılacak şekilde sabitlendiğinde. Daha sonra başvurumun tamamını / bir kısmını GAE'ye dağıtabileceğime veya çok fazla yeniden düzenleme yapmadan dağıtılmış depolama / harita azaltma la hbase / hadoop / cassandra'dan yararlanabileceğime eminim.

Datanucleus ile başlamanın ilk engelini biraz zor buldum - Datanucleus web sitesindeki belgelere girmek biraz zor - öğreticiler istediğim gibi takip etmek kolay değil. Bununla birlikte, ilk öğrenme eğrisini geçtikten sonra API ve haritalandırma hakkında daha ayrıntılı belgeler çok iyi.

Cevap, ne istediğinize bağlı. Daha temiz bir kod, daha fazla satıcı kilidi yok, daha pojo odaklı, nosql seçenekleri ayetler daha popüler olurdu.

Diğer geliştiricilerin / koyunların çoğuyla aynı şekilde yaptığınız sıcak telaşlı hissi istiyorsanız, JPA / hazırda bekletme'yi seçin. Alanınızda liderlik yapmak istiyorsanız, JDO / Datanucleus'u test edin ve kendi kararınızı verin.

Yeni bir proje için hangisini önerirsiniz?

Ben de öneririm! Kullanım Bahar DAO var JdbcTemplatebirlikte StoredProcedure, RowMapperve RowCallbackHandlerbunun yerine.

Hazırda Bekletme ile ilgili kişisel deneyimim, beklenmedik basamaklı güncelleme davranışı gibi sorunları anlamaya ve hata ayıklamaya çalışmak için satırdan geçireceğiniz sonsuz günlere kadar ön zamandan daha fazla dengelenmesi.

İlişkisel bir DB kullanıyorsanız, kodunuz ne kadar yakınsa, o kadar fazla kontrole sahip olursunuz. Spring'in DAO katmanı, eşleştirme katmanının ince kontrolüne izin verirken, kazan plakası koduna olan ihtiyacı ortadan kaldırır. Ayrıca, Spring'in işlem katmanına entegre olur, bu da kodunuza izinsiz girmeden (AOP aracılığıyla) karmaşık işlem davranışını kolayca ekleyebileceğiniz anlamına gelir (elbette bunu Hazırda Bekletme ile de alırsınız).

JDO öldü

JDO aslında ölmedi, bu yüzden lütfen gerçeklerinizi kontrol edin. JDO 2.2 Ekim 2008'de piyasaya sürüldü JDO 2.3 geliştirilme aşamasındadır.

Bu, Apache altında açıkça geliştirildi. JPA'nın sahip olduğundan daha fazla sürüm ve ORM spesifikasyonu, JPA2'nin önerdiği özelliklerden bile önce

JDO, JPA'dan daha gelişmiş özelliklere sahiptir bkz. Http://db.apache.org/jdo/jdo_v_jpa.html

JPA (5+ yaşında ve son derece hızlı / güvenilir KODO JDO kod tabanına dayanan Apache'den OpenJPA uygulaması) kullanıyorum. IMHO teknik özellikleri atlamanızı söyleyen herkes size kötü tavsiyeler veriyor. Zamanı içeri girdim ve kesinlikle ödüllendirildim. JDO veya JPA ile satıcıları minimum değişikliklerle değiştirebilirsiniz (JPA'nın orm eşlemesi vardır, bu nedenle satıcıları değiştirmek için bir günden az konuşuyoruz). Benim yaptığım gibi 100 + tablolarınız varsa bu çok büyük. Ayrıca küme tabanlı önbellek tahliyeleri ve hepsi iyi ile önbellek oluşturdunuz. SQL / Jdbc, yüksek performanslı sorgular için iyidir, ancak şeffaf kalıcılık, algoritmalarınızı ve veri giriş rutinlerinizi yazmak için çok daha üstündür. Tüm sistemimde sadece 16 SQL sorgusu var (50k + kod satırı).

Bunu kendim araştırıyorum ve ikisi arasında güçlü bir fark bulamıyorum. Bence büyük uygulama hangi uygulamayı kullandığınızdır. Kendim için ben dikkate oldum DataNucleus platformunu her ikisinin de veri deposu agnostik bir uygulaması olduğu için düşünüyorum.

JDO'nun öldüğünü söyleyen herkes, bir astroturfing FUD monger ve bunu biliyorlar.

JDO canlı ve iyi. Şartname hala çok daha genç ve kısıtlı JPA'dan daha güçlü, olgun ve gelişmiş.

Kendinizi sadece JPA standardında bulunanlarla sınırlamak istiyorsanız, JPA'ya yazabilir ve DataNucleus'u diğer JPA uygulamalarından daha yüksek performanslı, daha şeffaf bir kalıcılık uygulaması olarak kullanabilirsiniz. Elbette JDO'nun getirdiği modellemenin esnekliğini ve verimliliğini istiyorsanız DataNucleus ayrıca JDO standardını uygular.

Aynı projede Hibernate (JPA uygulaması) ve JPOX (JDO uygulaması) kullandım. JPOX tamam çalıştı, ancak o zaman desteklemediği bazı Java 5 dil özelliklerinin olduğu yerlerde oldukça hızlı bir şekilde hatalara girdi. XA işlemlerinde hoş oynama problemleri vardı. JDO nesnelerinden veritabanı şeması oluşturuyordum. Oracle bağlantınız çalışmıyorsa her seferinde bir veritabanına bağlanmak istedi.

Ardından Hazırda Bekletme moduna geçtik. Bir süre saf JPA kullanarak oynadık, ancak eşleme yapmak için Hazırda Bekletme özel özelliklerinden bazılarını kullanmamız gerekiyordu. Aynı kodu birden çok veritabanında çalıştırmak çok kolaydır. Hazırda bekletme, nesneleri agresif bir şekilde önbelleğe alıyor veya bazen garip bir önbellekleme davranışına sahip gibi görünüyor. Hibernate'in işleyemediği birkaç DDL yapısı vardır ve bu nedenle veritabanını başlatmak için çalıştırılan ek bir dosyada tanımlanırlar. Bir Hazırda Bekletme sorunuyla karşılaştığımda, çoğu zaman aynı sorunla karşılaşan birçok kişi vardır, bu da çözüm için googling'i kolaylaştırır. Son olarak, Hibernate iyi tasarlanmış ve güvenilir görünüyor.

Diğer bazı yanıtlayıcılar sadece SQL kullanmanızı önerdi. Nesne ilişkisel haritalama için gerçek katil kullanım durumu test ve geliştirmedir. Büyük hacimli verileri işlemek için oluşturulmuş veritabanları genellikle pahalıdır ve kurulması zordur. Test etmek zor. Test etmek için kullanılabilecek, ancak genellikle üretim için işe yaramayan çok sayıda bellek içi Java veritabanı vardır. Gerçek fakat sınırlı bir veritabanı kullanabilmek, geliştirme verimliliğini ve kod güvenilirliğini artıracaktır.

Mayıs 2012'de JDO 3.0 ve DataNucleus 3.0 kullanan örnek bir WebApp yaptım - ne kadar temiz olduğuna bir göz atın: https://github.com/TorbenVesterager/BadAssWebApp

Tamam belki biraz temiz, çünkü POJO'ları hem veritabanı hem de JSON istemcisi için kullanıyorum, ama eğlenceli :)

Not: Birkaç SuppressWarnings ek açıklaması içerir (IntelliJ 11'de geliştirilmiştir)