Hibernate vs JPA vs JDO - pro dan kontra dari masing-masing? [Tutup]

174

Saya kenal dengan ORM sebagai konsep, dan saya bahkan menggunakan nHibernate beberapa tahun yang lalu untuk proyek .NET; Namun, saya belum mengikuti topik ORM di Jawa dan belum memiliki kesempatan untuk menggunakan salah satu alat ini.

Tapi, sekarang saya mungkin memiliki kesempatan untuk mulai menggunakan beberapa alat ORM untuk salah satu aplikasi kami, dalam upaya untuk menjauh dari serangkaian layanan web lama.

Saya mengalami kesulitan mengatakan perbedaan antara spesifikasi JPA, apa yang Anda dapatkan dengan perpustakaan Hibernate itu sendiri, dan apa yang ditawarkan JDO.

Jadi, saya mengerti bahwa pertanyaan ini agak terbuka, tetapi saya berharap untuk mendapatkan beberapa pendapat tentang:

  • Apa pro dan kontra dari masing-masing?
  • Mana yang akan Anda sarankan untuk proyek baru?
  • Apakah ada kondisi tertentu saat menggunakan satu kerangka kerja vs yang lain?
java hibernate orm jpa jdo matt b
sumber

Jawaban:

112

Beberapa catatan:

  • JDO dan JPA keduanya spesifikasi, bukan implementasi.
  • Idenya adalah Anda dapat menukar implementasi JPA, jika Anda membatasi kode Anda untuk menggunakan standar JPA saja. (Ditto untuk JDO.)
  • Hibernate dapat digunakan sebagai salah satu implementasi JPA tersebut.
  • Namun, Hibernate menyediakan API asli, dengan fitur di atas dan di luar JPA.

IMO, saya akan merekomendasikan Hibernate.

Ada beberapa komentar / pertanyaan tentang apa yang harus Anda lakukan jika Anda perlu menggunakan fitur khusus Hibernate. Ada banyak cara untuk melihat ini, tetapi saran saya adalah:

  • Jika Anda tidak khawatir dengan prospek vendor tie-in, maka tentukan pilihan Anda antara Hibernate, dan implementasi JPA dan JDO lainnya termasuk berbagai ekstensi spesifik vendor dalam pengambilan keputusan Anda.

  • Jika Anda khawatir dengan prospek vendor tie-in, dan Anda tidak dapat menggunakan JPA tanpa beralih ke ekstensi spesifik vendor, maka jangan gunakan JPA. (Ditto untuk JDO).

Pada kenyataannya, Anda mungkin perlu menukar seberapa besar Anda khawatir dengan ikatan vendor versus seberapa banyak Anda membutuhkan ekstensi spesifik vendor tersebut.

Dan ada faktor-faktor lain juga, seperti seberapa baik Anda / staf Anda mengetahui teknologi masing-masing, berapa banyak biaya produk dalam lisensi, dan cerita siapa yang Anda yakini tentang apa yang akan terjadi di masa depan untuk JDO dan JPA.

toolkit
sumber
8
toolkit, bagus dan pendek. Poin lain yang layak disebutkan adalah bahwa JPA tidak mencegah dari menggunakan fitur implementasi spesifik jika perlu. Itu berarti bahwa JPA memungkinkan Anda menggunakan fitur Hibernate ketika Hibernate adalah implementasi.
topchef
1
Apa keuntungan menggunakan JPA jika saya memerlukan beberapa fitur khusus dari Hibernate?
Bruno Reis
22
Catatan penting yang harus ditambahkan: Sementara JPA dan JDO keduanya memiliki dukungan yang sangat baik untuk RDBMSes JDO adalah agnostik 'datastore' sehingga tidak terbatas pada dunia RDBMS. Dengan gelombang besar NoSQL saat ini seseorang akan bijaksana untuk mempertimbangkan menggunakan standar kegigihan yang menghindari mengunci aplikasi mereka ke dunia * SQL tradisional. Aplikasi JDO dapat dengan mudah digunakan bukan data RDBMS. Daftar lengkap datastores didukung dapat ditemukan di: datanucleus.org/products/accessplatform/datastores.html
Volksman
2
@ Wolfman mengapa memilih berdasarkan apa yang mungkin terjadi? Tidak ada yang dapat menghentikan Anda dari memasukkan sesuatu yang lain nanti jika Anda akhirnya membutuhkan dukungan NoSQL ... KISS
TM.
1
@Bruno - bila Anda menggunakan bagian non-Hibernate-spesifik Hibernate, Anda sedang menggunakan JPA. Jelas, keuntungan dari membatasi diri Anda ke JPA murni adalah bahwa Anda dapat beralih ke implementasi JPA lain dengan lebih mudah.
Stephen C
69

Pastikan Anda mengevaluasi implementasi DataNucleus dari JDO. Kami mulai dengan Hibernate karena tampaknya sangat populer tetapi segera menyadari bahwa itu bukan solusi persistensi transparan 100%. Ada terlalu banyak peringatan dan dokumentasi penuh 'jika Anda memiliki situasi ini maka Anda harus menulis kode Anda seperti ini' yang menghilangkan kesenangan dari pemodelan dan pengkodean bebas seperti yang kita inginkan. JDO tidak pernah membuat saya menyesuaikan kode atau model untuk membuatnya berfungsi dengan baik. Saya hanya bisa mendesain dan kode POJO sederhana seolah-olah saya akan menggunakannya 'dalam memori' saja, namun saya bisa bertahan secara transparan.

Keuntungan lain dari JDO / DataNucleus dibandingkan hibernate adalah tidak memiliki semua overhead time run refleksi dan lebih hemat memori karena menggunakan peningkatan kode byte waktu bangun (mungkin menambah 1 detik waktu pembangunan Anda untuk proyek besar) daripada dari pola proksi bertenaga refleksi waktu berjalan hibernate.

Hal lain yang mungkin Anda anggap menjengkelkan dengan Hibernate adalah bahwa referensi yang Anda miliki tentang apa yang Anda pikirkan adalah objek ... sering kali 'proxy' untuk objek tersebut. Tanpa manfaat peningkatan kode byte, pola proxy diperlukan untuk memungkinkan pemuatan berdasarkan permintaan (yaitu menghindari menarik seluruh grafik objek ketika Anda menarik objek level atas). Bersiaplah untuk mengesampingkan sama dan kode hash karena objek yang Anda pikir Anda referensi sering kali hanya proxy untuk objek itu.

Berikut adalah contoh frustrasi yang akan Anda dapatkan dengan Hibernate yang tidak akan Anda dapatkan dengan JDO:

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

Jika Anda suka coding ke 'workarounds' maka, tentu saja, Hibernate adalah untuk Anda. Jika Anda menghargai pengembangan yang bersih, murni, berorientasi objek, dan digerakkan oleh model di mana Anda menghabiskan seluruh waktu Anda untuk pemodelan, desain, dan pengkodean, dan tidak ada satu pun dari itu untuk solusi yang buruk, maka habiskan beberapa jam untuk mengevaluasi JDO / DataNucleus . Jam yang diinvestasikan akan dibayar seribu kali lipat.

Perbarui Feb 2017

Untuk beberapa waktu sekarang DataNucleus mengimplementasikan standar ketekunan JPA di samping standar ketekunan JDO sehingga porting proyek JPA yang ada dari Hibernate ke DataNucleus harus sangat mudah dan Anda bisa mendapatkan semua manfaat DataNucleus yang disebutkan di atas dengan sedikit perubahan kode , jika ada. Jadi dalam hal pertanyaan, pilihan standar tertentu, JPA (hanya RDBMS) vs JDO (RDBMS + Tidak ada SQL + ODBMS + + lainnya), DataNucleus mendukung keduanya, Hibernate dibatasi hanya untuk JPA.

Kinerja pembaruan DB Hibernate

Masalah lain yang perlu dipertimbangkan ketika memilih ORM adalah efisiensi mekanisme pengecekannya yang kotor - yang menjadi sangat penting ketika perlu membangun SQL untuk memperbarui objek yang telah berubah dalam transaksi saat ini - terutama ketika ada banyak objek. Ada penjelasan teknis rinci tentang mekanisme pemeriksaan kotor Hibernate dalam jawaban SO ini: JPA dengan HIBERNATE masukkan sangat lambat

Volksman
sumber
3
Dan seperti yang kita semua tahu, peningkatan justru merupakan alasan mengapa JDO diadopsi secara masif!
Pascal Thivent
15
FUD dan astroturfing yang dipublikasikan dengan baik yang dieksekusi oleh para pemain Hibernate utama pada hari-hari awal sehubungan dengan JDO tidak kurang jujur ​​dan menjijikkan dan tidak diragukan lagi memiliki pengaruh pada adopsi JDO. Dewasa ini pengembang tahu bahwa peningkatan kode byte sama sekali bukan masalah dan sering menggunakannya untuk berbagai tujuan selain kegigihan. Pustaka peningkatan kode byte ASM baru sangat cepat sehingga Anda bahkan tidak punya waktu untuk mengambil napas sebelum selesai.
Volksman
7
Kegagalan JDO diprediksi sejak awal ( javalobby.org/forums/thread.jspa?forumID=46&threadID=1326 ) dan sebelum Hibernate sehingga Anda tidak dapat menyalahkan Hibernate untuk itu. Hibernate / Toplink berhasil ketika Sun dan JDO pemain (dan OODBMS mereka) gagal karena mereka jawaban yang lebih baik pada waktu itu, bukan karena pemasaran dan FUD. Titik. Siapa yang peduli jika ASM menyala cepat hari ini , itu tidak ada 5+ tahun yang lalu, ketika dibutuhkan dan JDO hanya kalah dalam pertempuran. JDO secara konseptual lebih unggul? Sayang sekali, itu gagal memiliki implementasi pemenang tepat waktu (dan tidak akan kembali karena JPA).
Pascal Thivent
2
Untuk mengilustrasikan kata-kata saya (belum posting lain yang menggambarkan rasa sakit yang dirasakan orang selama pengembangan atau mengapa Hibernate memenangkan pertempuran): mail-archive.com/[email protected]/… . Tampak jelas bagi saya bahwa refleksi / cglib adalah jawaban praktis untuk masalah orang-orang (dan orang-orang tidak peduli jika suatu API secara konseptual lebih unggul jika sulit digunakan) dan saya tidak melihat ada pemain kunci Hibernasi di sini, hanya pengguna . Jadi pada akhirnya saya bertanya-tanya siapa yang menyebarkan FUD sebenarnya ...
Pascal Thivent
7
Yah ini tentu saja tidak seperti masa lalu di mana akan ada setidaknya 17 pos FUD Hibernate pro yang berbeda (namun hanya berasal dari 3 alamat IP yang berbeda. Apakah orang-orang matematika =)).
Volksman
54

Saya baru-baru ini mengevaluasi dan memilih kerangka kerja bertahan untuk proyek java dan temuan saya adalah sebagai berikut:

Apa yang saya lihat adalah bahwa dukungan yang mendukung JDO terutama:

  • Anda dapat menggunakan sumber data non-sql, db4o, hbase, ldap, bigtable, couchdb (plugin untuk cassandra) dll.
  • Anda dapat dengan mudah beralih dari sumber data sql ke non-sql dan sebaliknya.
  • tidak ada objek proxy dan karenanya lebih sedikit rasa sakit sehubungan dengan implementasi kode hash () dan equals ()
  • lebih banyak POJO dan karenanya lebih sedikit penyelesaian yang dibutuhkan
  • mendukung lebih banyak jenis hubungan dan bidang

dan dukungan yang mendukung JPA terutama:

  • lebih populer
  • jdo sudah mati
  • tidak menggunakan peningkatan bytecode

Saya melihat banyak posting pro-JPA dari pengembang JPA yang jelas-jelas tidak menggunakan JDO / Datanucleus yang menawarkan argumen yang lemah karena tidak menggunakan JDO.

Saya juga melihat banyak posting dari pengguna JDO yang telah bermigrasi ke JDO dan hasilnya jauh lebih bahagia.

Sehubungan dengan JPA menjadi lebih populer, tampaknya ini sebagian karena dukungan vendor RDBMS daripada yang secara teknis unggul. (Kedengarannya seperti VHS / Betamax bagi saya).

JDO dan implementasi rujukannya Datanucleus jelas tidak mati, seperti yang ditunjukkan oleh adopsi Google untuk GAE dan pengembangan aktif pada kode sumber (http://sourceforge.net/projects/datanucleus/).

Saya telah melihat sejumlah keluhan tentang JDO karena peningkatan bytecode, tetapi belum ada penjelasan mengapa itu buruk.

Bahkan, di dunia yang semakin terobsesi oleh solusi NoSQL, JDO (dan implementasi datanucleus) tampaknya taruhan yang jauh lebih aman.

Saya baru saja mulai menggunakan JDO / Datanucleus dan mengaturnya sehingga saya dapat beralih dengan mudah antara menggunakan db4o dan mysql. Sangat membantu untuk pengembangan cepat untuk menggunakan db4o dan tidak perlu terlalu khawatir tentang skema DB dan kemudian, setelah skema tersebut distabilkan untuk digunakan ke database. Saya juga merasa yakin bahwa nantinya, saya bisa mengerahkan semua / sebagian dari aplikasi saya ke GAE atau memanfaatkan penyimpanan terdistribusi / mengurangi peta a la hbase / hadoop / cassandra tanpa terlalu banyak refactoring.

Saya menemukan rintangan awal untuk memulai dengan Datanucleus sedikit rumit - Dokumentasi di situs web datanucleus agak sulit untuk dipahami - tutorialnya tidak mudah diikuti seperti yang saya inginkan. Karena itu, dokumentasi yang lebih rinci tentang API dan pemetaan sangat baik setelah Anda melewati kurva pembelajaran awal.

Jawabannya, itu tergantung apa yang Anda inginkan. Saya lebih suka memiliki kode yang lebih bersih, opsi no-vendor-lock-in, lebih berorientasi pojo, nosql lebih populer.

Jika Anda ingin perasaan rewel hangat bahwa Anda melakukan hal yang sama dengan mayoritas pengembang lain / domba, pilih JPA / hibernasi. Jika Anda ingin memimpin di bidang Anda, uji drive JDO / Datanucleus dan buat pikiran Anda sendiri.

Tom
sumber
9
Sebenarnya, seperti yang saya katakan, saya hanya memberi kesan pada apa yang saya temukan ketika mencoba untuk mengambil solusi. Ya saya seorang pemula di Jawa, mengapa harus begitu relavent? Anda, di sisi lain telah memposting beberapa kali menyatakan pendapat Anda bahwa JDO sudah mati tanpa menawarkan fakta atau bukti untuk membuktikannya dan tidak mengakui bidang teknis di mana JDO jelas lebih unggul. Anda jelas memiliki sesuatu yang bersifat pribadi terhadap JDO / Datanucleus dan menggunakan utas ini sebagai sarana untuk melanggengkan sikap anti-JDO Anda.
Tom
4
Pascal - Anda memperdebatkan diri Anda ke sudut sini. Saya pikir Anda kehilangan titik bagian Periklanan pada FAQ. OP meminta pendapat tentang 2 teknologi. Ini mengundang mereka yang mendukung kedua belah pihak untuk maju dan menyampaikan kritik / rekomendasi konstruktif mereka. Bagi Andy / Datanucleus dan pengguna JDO lainnya untuk menyoroti positif JDO dan bertahan melawan kritik tidak lebih dari iklan daripada orang lain di sini merekomendasikan untuk menggunakan hibernate.
Tom
5
Anda sebaiknya merujuk ke bagian FAQ yang bertuliskan 'Be Nice' karena posting Anda tentang topik ini bersifat accusatorial, konfrontatif, atau kasar. Yang pertama adalah komentar sarkastik tentang peningkatan. Kedua; kata-kata kasar pada kesulitan implementasi awal dan tidak lagi relevan. Ketiga adalah cemoohan kekanak-kanakan dan penghinaan bagi mereka yang mungkin memilih untuk tidak menggunakan RDBMS. Keempat adalah ejekan sarkastik terhadap seseorang yang memiliki pandangan berbeda dengan Anda. Kelima adalah serangan; memanggil saya burung beo. Apakah Anda menganggap ini 'Menjadi baik'?
Tom
3
Jika Anda memiliki pengalaman mengerikan dengan JDO, maka jelaskan apa yang mengerikan, akui bahwa itu dengan versi yang lebih lama dan hal-hal mungkin telah diperbaiki sejak saat itu. Anda juga perlu menyadari bahwa orang lain mungkin memiliki kebutuhan yang berbeda dengan Anda. Hanya karena Anda 'puas' dengan JPA dan ingin menggunakan RDBMS tidak berarti orang lain juga. Mungkin karena tergesa-gesa untuk meningkatkan reputasi Anda, Anda telah kehilangan pandangan tentang reputasi apa yang ada untuk diberikan? ps. Sebagai pengembang, Anda harus benar-benar tertarik pada kesejahteraan proyek seperti itulah yang mendorong inovasi dan mengurangi vendor-lock-in.
Tom
6
Ini akan menjadi jawaban terakhir saya :) .. 1. Jika tidak relaven mempertanyakan mengapa mengajukannya? 2. Saya tidak pernah mempertanyakan kejujuran Anda, saya mengatakan Anda tidak bersikap baik terhadap poster lain dan bahwa Anda bertentangan dengan diri Anda sendiri. 3. tidak ada yang menyarankan Anda merangkum 8+ tahun - tetapi buatlah cadangan pernyataan Anda dengan fakta dan contoh daripada pernyataan subjektif yang cenderung menyinggung. 5. Di mana sikap 'hibernate / jpa / jboss is evil' pada posting ini? Saya tidak melihatnya. Saya hanya melihat komentar anti-JDO Anda.
Tom
40

Mana yang akan Anda sarankan untuk proyek baru?

Saya tidak akan menyarankan! Gunakan Spring DAO'sJdbcTemplate bersama StoredProcedure, RowMapperdan RowCallbackHandlersebagai gantinya.

Pengalaman pribadi saya sendiri dengan Hibernate adalah bahwa waktu yang dihemat di muka lebih dari diimbangi dengan hari-hari tanpa henti yang akan Anda habiskan untuk mencoba memahami dan men-debug masalah seperti perilaku pembaruan berjenjang yang tidak terduga.

Jika Anda menggunakan DB relasional maka semakin dekat kode Anda, semakin banyak kontrol yang Anda miliki. Lapisan DAO Spring memungkinkan kontrol yang baik dari layer pemetaan, sambil menghilangkan kebutuhan untuk kode boilerplate. Juga, itu terintegrasi ke dalam lapisan transaksi Spring yang berarti Anda dapat dengan mudah menambahkan (melalui AOP) perilaku transaksional yang rumit tanpa mengganggu ke dalam kode Anda (tentu saja, Anda mendapatkan ini dengan Hibernate juga).

oxbow_lakes
sumber
4
ini jelas merupakan pilihan pemetaan anti-objek-relasional (ORM) yang didorong oleh pengguna besar dan basis kode yang terakumulasi sejak masa ODBC (awal 90-an) (baca warisan). Tidak ada alasan untuk tidak menggunakan JDBC (dengan atau tanpa Spring) kecuali Anda memilih untuk melanjutkan dan menggunakan kerangka kerja ORM. Pikirkan orang-orang yang suatu hari memutuskan untuk meninggalkan FORTRAN untuk menggunakan C atau Pascal.
topchef
23
@ grory - Saya berbicara dengan banyak pengalaman menghabiskan hari-hari untuk mencoba memahami masalah Hibernate, seperti pembaruan / penghapusan cascading, struktur kueri yang sangat tidak efisien, dll. Solusi ORM adalah "kemenangan cepat" bagi mereka yang kurang paham tentang basis data relasional. Dengan demikian, tidak mungkin bahwa pengetahuan tentang Hibernate saja akan menghasilkan produk akhir yang baik. Ini pengalaman saya bahwa, selama siklus hidup proyek, Hibernate (dan ORM dengan ekstensi) menghabiskan lebih banyak waktu daripada menghemat
oxbow_lakes
8
maaf Anda memiliki pengalaman buruk dengan Hibernate. Saya berasal dari database yang berat / SQL / prosedur tersimpan / sekolah JDBC sendiri. Saya tidak bisa mengatakan saya murtad - setiap teknologi di atas masih memiliki tempatnya. Tetapi untuk tujuan umum aplikasi Java 3-tier (berapapun ukurannya) pilihan pertama adalah teknologi ORM - lebih disukai JPA 2. Yang lain harus dipertimbangkan berdasarkan faktor-faktor seperti kode warisan, integrasi, keahlian, persyaratan batch-berat, real-time kinerja, dll. yang mungkin mengarahkan (atau mungkin tidak) pendekatan ke arah tumpukan teknologi basis data yang berbeda.
topchef
3
Saya benar-benar tidak setuju dengan definisi "cepat-menang" di atas - ambil Hibernate in Action ( stackoverflow.com/questions/96729/… ) (dan JPA 1, dengan JPA 2 hanya akan lebih baik) untuk memahami sepenuhnya daya dan cakupan teknologi ini. telah.
topchef
7
Saya melakukan sedikit riset dan Spring tidak lagi merekomendasikan Spring DAO ( static.springsource.org/spring/docs/3.0.x/… ): "Gaya integrasi yang disarankan adalah untuk mengkode DAO terhadap API Hibernate, JPA, dan JDO. gaya lama menggunakan templat DAO Spring tidak lagi direkomendasikan; "... Apakah ini yang Anda rekomendasikan? Jika demikian, mengapa mereka tidak merekomendasikannya?
Pengguna1
23

JDO sudah mati

JDO tidak mati sebenarnya jadi silakan periksa fakta Anda. JDO 2.2 dirilis pada Oktober 2008 JDO 2.3 sedang dalam pengembangan.

Ini dikembangkan secara terbuka, di bawah Apache. Lebih banyak rilis dari yang dimiliki JPA, dan spesifikasi ORMnya masih lebih maju dari fitur yang diusulkan JPA2

DataNucleus
sumber
12
Orang-orang pasti menggunakannya, sebagaimana dibuktikan oleh banyak pengguna yang dimiliki DataNucleus, apalagi Xcalia, Kodo. Anda melewatkan ide dasar bahwa JDO dan JPA tidak mengisi pasar yang sama. JPA secara eksklusif RDBMS. JDO adalah agnostik datastore dan digunakan untuk RDBMS, tetapi juga LDAP, XML, Excel, OODBMs, dll.
DataNucleus
3
Saya suka faktor non-RDBMS, terutama dengan meningkatnya popularitas solusi non-RDBMS, ini masalah besar. Ini berarti bahwa jika JPA tidak berkembang cukup cepat, ketersediaan alternatif "lebih terbuka" dan fleksibel (JDO) berarti bahwa popularitas JPA akan cenderung menurun, karena kebutuhan. Jangankan argumen teknis bahwa JDO lebih lengkap, unggul, dewasa, atau apa pun - itu tidak akan menjadi masalah preferensi . Masuk akal bahwa vendor RDBMS berperilaku mencurigakan - hari-hari dominasi pasar RDBMS mungkin akan berakhir.
Manius
Kami masih menggunakan JDO / DataNucleus pada tahun 2019! Sekarang hingga Versi 5.x dan masih mengalahkan Hibernate untuk produktivitas pengembang dan kinerja runtime. Baru-baru ini saya harus melakukan konsultasi pada aplikasi web besar menggunakan Hibernate dan diingatkan tentang rasa sakit yang saya derita ketika saya adalah pengguna dan promotor HIbernate yang aktif bertahun-tahun yang lalu, seorang pemimpin tim tidak mempercayai saya ketika saya mengatakan kepadanya bahwa bidang BLOB-nya selalu bersemangat diambil meskipun itu ditandai sebagai malas diambil. Kurangnya pengetahuan "di balik tudung" sepenuhnya oleh seorang ahli Hibernate yang "berpengalaman" memproklamirkan dengan sedih mengganggu tetapi diharapkan.
Volksman
15

JDO memiliki fitur-fitur canggih daripada JPA, lihat http://db.apache.org/jdo/jdo_v_jpa.html

Sandeep Manne
sumber
Sangat benar! Tapi sepertinya tidak ada yang mengetahuinya ...
marcolopes
10

Saya menggunakan JPA (implementasi OpenJPA dari Apache yang didasarkan pada basis kode KODO JDO yang berusia 5+ tahun dan sangat cepat / dapat diandalkan). IMHO siapa pun yang memberitahu Anda untuk memintas spesifikasi memberikan Anda nasihat buruk. Saya menaruh waktu dan pasti dihargai. Dengan JDO atau JPA Anda dapat mengubah vendor dengan perubahan minimal (JPA memiliki pemetaan orm jadi kami berbicara kurang dari sehari untuk kemungkinan mengubah vendor). Jika Anda memiliki 100+ tabel seperti yang saya lakukan ini sangat besar. Plus Anda mendapatkan caching built0in dengan pengusiran cache cluster-wise dan semuanya baik. SQL / Jdbc baik untuk permintaan kinerja tinggi tetapi ketekunan transparan jauh lebih unggul untuk menulis algoritma dan rutinitas input data. Saya hanya memiliki sekitar 16 query SQL di seluruh sistem saya (50k + baris kode).


sumber
8

Saya sudah melihat ini sendiri dan tidak dapat menemukan perbedaan yang kuat antara keduanya. Saya pikir pilihan besar adalah implementasi yang Anda gunakan. Untuk saya sendiri, saya telah mempertimbangkan platform DataNucleus karena merupakan implementasi agnostik data-store dari keduanya.

tapi
sumber
6
+1 untuk DataNucleus, bukan untuk jawabannya.
WolfmanDragon
8

Siapa pun yang mengatakan bahwa JDO sudah mati adalah penjual FUD astroturfing dan mereka tahu itu.

JDO hidup dan sehat. Spesifikasi ini masih lebih kuat, lebih matang dan lebih maju daripada JPA yang jauh lebih muda dan terbatas.

Jika Anda ingin membatasi diri hanya pada apa yang tersedia dalam standar JPA, Anda dapat menulis ke JPA dan menggunakan DataNucleus sebagai implementasi persistensi yang berkinerja tinggi dan lebih transparan daripada implementasi JPA lainnya. Tentu saja DataNucleus juga mengimplementasikan standar JDO jika Anda menginginkan fleksibilitas dan efisiensi pemodelan yang dibawa JDO.

Volksman
sumber
1
Atau Anda menggunakan implementasi (baik) lainnya dengan komunitas yang jauh lebih besar dan akibatnya lebih responsif. Ya, beberapa orang juga peduli akan hal itu.
Pascal Thivent
1
Dan Anda berbicara tentang FUD> :) Lucu.
Pascal Thivent
2
Komentar Anda tampaknya menganggap bahwa saya belum menggunakan Hibernate dan JDO.
Volksman
2
Utas ini tampaknya memiliki banyak sekali referensi dari beberapa orang tentang betapa hebatnya DataNucleus. Tolong jangan gunakan tempat ini sebagai platform iklan Anda.
TM.
3
Tidak ada yang mengejutkan dari Golfman yang menempelkan hal-hal pemasaran putus asa yang sama berulang-ulang di setiap utas yang melibatkan JPA atau DataNucleus (yang dia gunakan sejak 1996 , bahkan sebelum itu ada !).
Pascal Thivent
2

Saya telah menggunakan Hibernate (implementasi JPA) dan JPOX (implementasi JDO) dalam proyek yang sama. JPOX bekerja dengan baik, tetapi bertemu dengan bug dengan cukup cepat, di sana ada beberapa fitur Java 5 bahasa yang tidak didukung pada saat itu. Itu memiliki masalah bermain baik dengan transaksi XA. Saya menghasilkan skema database dari objek JDO. Itu ingin terhubung ke database setiap kali yang menjengkelkan jika koneksi Oracle Anda tidak berfungsi.

Kami kemudian beralih ke Hibernate. Kami bermain-main dengan hanya menggunakan JPA murni untuk sementara, tapi kami perlu menggunakan beberapa fitur khusus Hibernate untuk melakukan pemetaan. Menjalankan kode yang sama pada banyak basis data sangat mudah. Hibernate tampaknya men-cache objek secara agresif atau hanya memiliki perilaku caching yang aneh di kali. Ada beberapa konstruksi DDL yang tidak dapat ditangani Hibernate dan mereka didefinisikan dalam file tambahan yang dijalankan untuk menginisialisasi database. Ketika saya mengalami masalah Hibernate, sering ada banyak orang yang mengalami masalah yang sama yang membuat googling untuk solusi lebih mudah. Akhirnya, Hibernate tampaknya dirancang dengan baik dan dapat diandalkan.

Beberapa responden lain menyarankan hanya menggunakan SQL. Kasus penggunaan pembunuh nyata untuk pemetaan relasional objek adalah pengujian dan pengembangan. Basis data yang dibangun untuk menangani volume data yang besar biasanya mahal dan atau mereka sulit dipasang. Mereka sulit untuk diuji. Ada banyak basis data Java dalam memori yang dapat digunakan untuk mengujinya, tetapi biasanya tidak berguna untuk produksi. Mampu menggunakan database nyata, tetapi terbatas, akan meningkatkan produktivitas pengembangan dan keandalan kode.

Sean McCauliff
sumber
1
Sejauh yang saya tahu, JPOX mengubah nama menjadi DataNucleus (dan telah memiliki rilis sejak itu).
Donal Fellows
2
Berpikir Anda akan benar-benar menemukan bahwa DataNucleus memiliki bug yang jauh lebih terbuka daripada perangkat lunak lain yang Anda referensikan. Pikir Anda juga akan menemukan bahwa pengembangan DataNucleus mengurangi jumlah bug pada tingkat yang lebih cepat daripada perangkat lunak lain juga.
DataNucleus
1

Saya membuat sampel WebApp pada Mei 2012 yang menggunakan JDO 3.0 & DataNucleus 3.0 - lihat betapa bersihnya: https://github.com/TorbenVesterager/BadAssWebApp

Oke mungkin itu agak terlalu bersih, karena saya menggunakan POJO baik untuk database dan klien JSON, tapi itu menyenangkan :)

PS: Berisi beberapa anotasi SuppressWarnings (dikembangkan di IntelliJ 11)

Torben Vesterager
sumber