ไฮเบอร์เนตกับ JPA เทียบกับ JDO ข้อดีและข้อเสียของแต่ละ? [ปิด]

ฉันคุ้นเคยกับ ORM เป็นแนวคิดและฉันใช้ nHibernate หลายปีที่ผ่านมาสำหรับโครงการ. NET อย่างไรก็ตามฉันไม่ได้ติดตามหัวข้อ ORM ใน Java และไม่ได้มีโอกาสใช้เครื่องมือเหล่านี้

แต่ตอนนี้ฉันอาจมีโอกาสเริ่มใช้เครื่องมือ ORM บางอย่างสำหรับหนึ่งในแอปพลิเคชันของเราในความพยายามที่จะย้ายออกจากชุดบริการเว็บดั้งเดิม

ฉันมีเวลายากที่จะบอกความแตกต่างระหว่างข้อกำหนด JPA สิ่งที่คุณจะได้รับจากห้องสมุด Hibernate และสิ่งที่ JDO มีให้

ดังนั้นฉันเข้าใจว่าคำถามนี้เป็นบิตปลายเปิด แต่ฉันหวังว่าจะได้รับความคิดเห็นบางอย่างเกี่ยวกับ:

• ข้อดีและข้อเสียของแต่ละข้อคืออะไร?
• คุณต้องการแนะนำโครงการใหม่แบบใด
• มีเงื่อนไขบางประการหรือไม่ที่จะใช้กรอบหนึ่งกับอีกกรอบหนึ่ง

หมายเหตุบางส่วน:

• JDO และ JPA เป็นทั้งข้อมูลจำเพาะไม่ใช่การนำไปใช้งาน
• แนวคิดคือคุณสามารถสลับการใช้งาน JPA ได้หากคุณ จำกัด รหัสของคุณให้ใช้ JPA มาตรฐานเท่านั้น (เช่นเดียวกันสำหรับ JDO)
• ไฮเบอร์เนตสามารถใช้เป็นการดำเนินการอย่างหนึ่งของ JPA
• อย่างไรก็ตาม Hibernate มี API ดั้งเดิมพร้อมด้วยคุณสมบัติที่เหนือกว่า JPA

IMO ฉันจะแนะนำ Hibernate

มีความคิดเห็น / คำถามเกี่ยวกับสิ่งที่คุณควรทำถ้าคุณจำเป็นต้องใช้คุณสมบัติเฉพาะของไฮเบอร์เนต มีหลายวิธีในการดูสิ่งนี้ แต่คำแนะนำของฉันคือ:

• หากคุณไม่กังวลเกี่ยวกับความคาดหวังของผู้ขายให้เลือกตัวเลือกระหว่าง Hibernate และการใช้งาน JPA และ JDO อื่น ๆรวมถึงส่วนขยายเฉพาะของผู้ขายต่าง ๆ ในการตัดสินใจของคุณ

• หากคุณกังวลเกี่ยวกับความคาดหวังของการผูกมัดผู้จำหน่ายและคุณไม่สามารถใช้ JPA ได้โดยไม่ต้องหันไปใช้ส่วนขยายเฉพาะของผู้จำหน่ายดังนั้นอย่าใช้ JPA (เช่นเดียวกันสำหรับ JDO)

ในความเป็นจริงคุณอาจจะต้องมีการค้าออกเท่าไหร่ที่คุณมีความกังวลใจโดยผู้ผลิตผูกอยู่กับวิธีการมากที่คุณต้องนามสกุลเฉพาะผู้ขายเหล่านั้น

และยังมีปัจจัยอื่น ๆ เช่นคุณ / พนักงานของคุณรู้จักเทคโนโลยีที่เกี่ยวข้องดีแค่ไหนค่าใช้จ่ายในการออกใบอนุญาตจำนวนเท่าไรและเรื่องราวที่คุณเชื่อว่าจะเกิดขึ้นในอนาคตสำหรับ JDO และ JPA

ตรวจสอบให้แน่ใจว่าคุณประเมินการใช้งาน DataNucleus ของ JDO เราเริ่มต้นด้วย Hibernate เพราะดูเหมือนจะได้รับความนิยม แต่ในไม่ช้าก็รู้ว่ามันไม่ใช่วิธีการคงอยู่ที่โปร่งใส 100% มีจำนวนคำเตือนมากเกินไปและเอกสารประกอบเต็มไปด้วย 'หากคุณมีสถานการณ์นี้คุณต้องเขียนโค้ดของคุณแบบนี้' ซึ่งทำให้ความสนุกในการสร้างแบบจำลองและการเข้ารหัสได้อย่างอิสระตามที่เราต้องการ JDO ไม่เคยทำให้ฉันต้องปรับรหัสหรือโมเดลของฉันเพื่อให้มัน 'ทำงานอย่างถูกต้อง' ฉันสามารถออกแบบและเขียนรหัส POJO แบบง่าย ๆ ได้ราวกับว่าฉันจะใช้พวกเขา 'ในหน่วยความจำ' เท่านั้น แต่ฉันสามารถยืนยันได้อย่างโปร่งใส

ข้อได้เปรียบอื่น ๆ ของ JDO / DataNucleus มากกว่าการจำศีลคือมันไม่ได้มีค่าใช้จ่ายในการสะท้อนเวลาทำงานทั้งหมดและมีหน่วยความจำที่มีประสิทธิภาพมากขึ้นเพราะใช้การปรับปรุงโค้ดไบต์เวลาสร้าง (อาจเพิ่ม 1 วินาทีในการสร้างโครงการขนาดใหญ่) มากกว่ารูปแบบพร็อกซีที่ได้รับการสนับสนุนที่สะท้อนเวลาของไฮเบอร์เนต

สิ่งที่คุณอาจพบว่าน่ารำคาญกับ Hibernate ก็คือการอ้างอิงที่คุณมีต่อสิ่งที่คุณคิดว่าเป็นวัตถุ ... มันมักจะเป็น 'พร็อกซี' สำหรับวัตถุ หากไม่ได้รับประโยชน์จากการเพิ่มรหัสไบต์รูปแบบพร็อกซีจำเป็นต้องอนุญาตให้โหลดตามความต้องการ (เช่นหลีกเลี่ยงการดึงกราฟวัตถุทั้งหมดของคุณเมื่อคุณดึงวัตถุระดับบนสุด) ได้เตรียมที่จะแทนที่เท่ากับและ hashcode เพราะวัตถุที่คุณคิดว่าคุณอ้างอิงมักจะเป็นเพียงตัวแทนสำหรับวัตถุนั้น

นี่คือตัวอย่างของความผิดหวังที่คุณจะได้รับด้วย Hibernate ที่คุณจะไม่ได้รับจาก JDO:

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

หากคุณต้องการให้รหัส 'การแก้ไขปัญหา' แน่นอนว่าไฮเบอร์เนตเหมาะสำหรับคุณ ถ้าคุณชื่นชมสะอาดบริสุทธิ์วัตถุที่มุ่งเน้นการพัฒนารูปแบบการขับเคลื่อนที่คุณใช้จ่ายตลอดเวลาของคุณในการสร้างแบบจำลองการออกแบบและการเข้ารหัสและไม่มีมันในการแก้ไขปัญหาที่น่าเกลียดแล้วใช้จ่ายไม่กี่ชั่วโมงประเมินJDO / DataNucleus ชั่วโมงการลงทุนจะได้รับการชำระคืนเป็นพันเท่า

อัพเดท ก.พ. 2560

ในขณะนี้ DataNucleus ใช้มาตรฐาน JPA persistence นอกเหนือจาก JDO persistence standard ดังนั้นการย้ายโครงการ JPA ที่มีอยู่จาก Hibernate ไปยัง DataNucleus ควรตรงไปตรงมาและคุณจะได้รับประโยชน์ทั้งหมดที่กล่าวถึงข้างต้นจาก DataNucleus , ถ้ามี. ดังนั้นในแง่ของคำถามการเลือกมาตรฐานเฉพาะ JPA (RDBMS เท่านั้น) เทียบกับ JDO (RDBMS + ไม่มี SQL + ODBMSes + อื่น ๆ ) DataNucleus สนับสนุนทั้งสองไฮเบอร์เนตจึงถูก จำกัด ให้ JPA เท่านั้น

ประสิทธิภาพของการอัพเดต DB ของไฮเบอร์เนต

อีกประเด็นที่ควรพิจารณาเมื่อเลือก ORM คือประสิทธิภาพของกลไกการตรวจสอบที่สกปรกซึ่งมีความสำคัญอย่างยิ่งเมื่อต้องสร้าง SQL เพื่ออัปเดตวัตถุที่มีการเปลี่ยนแปลงในธุรกรรมปัจจุบัน - โดยเฉพาะอย่างยิ่งเมื่อมีวัตถุจำนวนมาก มีคำอธิบายทางเทคนิคโดยละเอียดเกี่ยวกับกลไกการตรวจสอบที่สกปรกของ Hibernate ในคำตอบ SO นี้: JPA พร้อม HIBERNATE แทรกช้ามาก

ฉันเพิ่งได้รับการประเมินและเลือกกรอบการติดตาสำหรับโครงการ java และการค้นพบของฉันมีดังนี้:

สิ่งที่ฉันเห็นคือการสนับสนุนJDOนั้นสำคัญที่สุด:

• คุณสามารถใช้แหล่งข้อมูลที่ไม่ใช่ sql, db4o, hbase, ldap, bigtable, couchdb (ปลั๊กอินสำหรับคาสซานดรา) เป็นต้น
• คุณสามารถเปลี่ยนจากแหล่งข้อมูล sql เป็น non-sql datasource และในทางกลับกันได้
• ไม่มีวัตถุพร็อกซีและดังนั้นจึงมีความเจ็บปวดน้อยลงเกี่ยวกับการใช้ hashcode () และเท่ากับ ()
• POJO ที่มากขึ้นและการแก้ไขปัญหาจึงน้อย
• รองรับความสัมพันธ์และประเภทฟิลด์เพิ่มเติม

และการสนับสนุนแก่JPAนั้นเป็นหลัก:

• เป็นที่นิยมมากขึ้น
• jdo ตายแล้ว
• ไม่ได้ใช้การปรับปรุง bytecode

ฉันเห็นโพสต์ Pro-JPA จำนวนมากจากผู้พัฒนา JPA ที่ไม่ได้ใช้ JDO / Datanucleus อย่างชัดเจนซึ่งเสนอข้อโต้แย้งที่อ่อนแอสำหรับการไม่ใช้ JDO

ฉันยังเห็นโพสต์จำนวนมากจากผู้ใช้ JDO ที่ย้ายมาที่ JDO และมีความสุขมากขึ้น

ในแง่ของ JPA ได้รับความนิยมมากขึ้นดูเหมือนว่านี่เป็นส่วนหนึ่งเนื่องจากการสนับสนุนผู้ขาย RDBMS มากกว่าที่จะเป็นเทคนิคที่เหนือกว่า (ฟังดูเหมือน VHS / Betamax กับฉัน)

การใช้งาน JDO และมันคือการอ้างอิง Datanucleus ยังไม่ตายอย่างที่แสดงโดยการยอมรับของ Google สำหรับ GAE และการพัฒนาอย่างแข็งขันในซอร์สโค้ด (http://sourceforge.net/projects/datanucleus/)

ฉันได้เห็นการร้องเรียนจำนวนมากเกี่ยวกับ JDO เนื่องจากการปรับปรุง bytecode แต่ยังไม่มีคำอธิบายว่าทำไมมันถึงไม่ดี

ในความเป็นจริงในโลกที่กำลังหมกมุ่นอยู่กับโซลูชั่น NoSQL มากขึ้น JDO (และการใช้งานฐานข้อมูล) ดูเหมือนจะปลอดภัยกว่ามาก

ฉันเพิ่งเริ่มใช้ JDO / Datanucleus และตั้งค่าเพื่อให้ฉันสามารถสลับระหว่างการใช้ db4o และ mysql ได้อย่างง่ายดาย มันมีประโยชน์สำหรับการพัฒนาอย่างรวดเร็วในการใช้ db4o และไม่ต้องกังวลมากเกินไปเกี่ยวกับ schema ของ DB จากนั้นเมื่อ schema นั้นมีความเสถียรในการปรับใช้กับฐานข้อมูล ฉันยังรู้สึกมั่นใจว่าในภายหลังฉันสามารถปรับใช้ทั้งหมด / บางส่วนของแอปพลิเคชันของฉันไปยัง GAE หรือใช้ประโยชน์จากที่เก็บข้อมูลแบบกระจาย / แผนที่ - ลด la hbase / hadoop / Cassandra โดยไม่ต้องทำการปรับสภาพมากเกินไป

ฉันพบอุปสรรค์เริ่มต้นของการเริ่มต้นใช้งาน Datanucleus นิดหน่อย - เอกสารบนเว็บไซต์ดาต้านิวเคลียสนั้นยากที่จะเข้าใจ - บทเรียนไม่ง่ายที่จะติดตามอย่างที่ฉันชอบ ต้องบอกว่าเอกสารรายละเอียดเพิ่มเติมเกี่ยวกับ API และการแมปนั้นดีมากเมื่อคุณผ่านช่วงการเรียนรู้เริ่มต้น

คำตอบคือมันขึ้นอยู่กับสิ่งที่คุณต้องการ ฉันอยากจะมีรหัสที่สะอาดกว่าไม่มีผู้ขายล็อคอินตัวเลือกเพิ่มเติม pojo-orientated, nosql ข้อที่นิยมมากขึ้น

หากคุณต้องการความรู้สึกจุกจิกอบอุ่นที่คุณกำลังทำเช่นเดียวกันกับนักพัฒนา / แกะส่วนใหญ่ให้เลือก JPA / hibernate หากคุณต้องการเป็นผู้นำในสาขาของคุณลองขับ JDO / Datanucleus และสร้างความคิดของคุณเอง

คุณต้องการแนะนำโครงการใหม่แบบใด

ฉันจะไม่แนะนำ! ใช้ฤดูใบไม้ผลิเป็น DAO JdbcTemplateร่วมกับStoredProcedure, RowMapperและRowCallbackHandlerแทน

ประสบการณ์ส่วนตัวของฉันกับไฮเบอร์เนตคือเวลาที่บันทึกไว้ล่วงหน้านั้นตรงข้ามกับวันที่ไม่รู้จบที่คุณจะต้องพยายามทำความเข้าใจและแก้ไขปัญหาเช่นพฤติกรรมการอัพเดตที่ไม่คาดคิด

หากคุณใช้ฐานข้อมูลเชิงสัมพันธ์ยิ่งรหัสของคุณใกล้เคียงกับคุณมากเท่าไหร่ก็ยิ่งมีการควบคุมมากขึ้นเท่านั้น ชั้น DAO ของสปริงอนุญาตให้ควบคุมเลเยอร์การแมปได้อย่างดีในขณะเดียวกันก็ไม่จำเป็นต้องใช้รหัสสำเร็จรูปอีกต่อไป นอกจากนี้ยังรวมเข้ากับเลเยอร์ธุรกรรมของสปริงซึ่งหมายความว่าคุณสามารถเพิ่ม (โดย AOP) พฤติกรรมการทำธุรกรรมที่ซับซ้อนได้อย่างง่ายดายโดยไม่ต้องบุกรุกเข้าไปในโค้ดของคุณ (แน่นอนคุณได้รับสิ่งนี้ด้วยไฮเบอร์เนต)

JDO ตายแล้ว

JDO ยังไม่ตายจริง ๆ ดังนั้นโปรดตรวจสอบข้อเท็จจริงของคุณ JDO 2.2 เปิดตัวในเดือนตุลาคม 2008 JDO 2.3 อยู่ระหว่างการพัฒนา

สิ่งนี้ได้รับการพัฒนาอย่างเปิดเผยภายใต้ Apache มีการเปิดตัวมากกว่า JPA และข้อมูลจำเพาะ ORM ของผลิตภัณฑ์นั้นยังอยู่ในขั้นตอนก่อนหน้าแม้แต่คุณสมบัติที่เสนอ JPA2

JDO มีคุณสมบัติขั้นสูงกว่า JPA ดูhttp://db.apache.org/jdo/jdo_v_jpa.html

ฉันใช้ JPA (การใช้งาน OpenJPA จาก Apache ซึ่งใช้ฐานรหัส KODO JDO ซึ่งมีอายุ 5 ปีขึ้นไปและรวดเร็ว / เชื่อถือได้มาก) ใครก็ตามที่บอกให้คุณหลีกเลี่ยงข้อกำหนดจะให้คำแนะนำที่ไม่ดีแก่คุณ ฉันใส่เวลาและได้รับรางวัลแน่นอน ด้วย JDO หรือ JPA คุณสามารถเปลี่ยนผู้ขายด้วยการเปลี่ยนแปลงที่น้อยที่สุด (JPA มีการทำแผนที่ orm ดังนั้นเราจึงพูดน้อยกว่าหนึ่งวันเพื่อเปลี่ยนผู้ให้บริการ) ถ้าคุณมี 100+ โต๊ะแบบฉันนี่มันใหญ่มาก นอกจากนี้คุณยังได้รับการสร้างแคชในตัวด้วยการล้างแคชแบบคลัสเตอร์และทั้งหมดนี้เป็นสิ่งที่ดี SQL / Jdbc นั้นใช้ได้กับการค้นหาที่มีประสิทธิภาพสูง แต่การเก็บข้อมูลแบบโปร่งใสนั้นเหนือกว่าสำหรับการเขียนอัลกอริทึมและรูทีนการป้อนข้อมูลของคุณ ฉันมีคิวรี่ SQL ประมาณ 16 รายการในระบบทั้งหมดของฉัน (50k + บรรทัดของโค้ด)

ฉันได้ค้นหาตัวเองและไม่สามารถค้นหาความแตกต่างที่แข็งแกร่งระหว่างสอง ฉันคิดว่าตัวเลือกที่สำคัญคือการใช้งานที่คุณใช้ สำหรับตัวฉันเองฉันกำลังพิจารณาแพลตฟอร์มDataNucleusเพราะเป็นระบบเก็บข้อมูลที่ไม่เชื่อเรื่องพระเจ้าของทั้งคู่

ใครก็ตามที่บอกว่า JDO ตายไปแล้วพวกเขาก็รู้ว่ามันคือ FUD monger

JDO ยังมีชีวิตอยู่และดี ข้อมูลจำเพาะยังคงมีประสิทธิภาพเป็นผู้ใหญ่และก้าวหน้ากว่า JPA ที่อายุน้อยกว่าและมีข้อ จำกัด

หากคุณต้องการ จำกัด ตัวเองให้มีเฉพาะสิ่งที่มีอยู่ในมาตรฐาน JPA คุณสามารถเขียนถึง JPA และใช้ DataNucleus เป็นประสิทธิภาพสูงการดำเนินการคงอยู่ที่โปร่งใสมากขึ้นกว่าการใช้ JPA อื่น ๆ แน่นอนว่า DataNucleus ยังใช้มาตรฐาน JDO หากคุณต้องการความยืดหยุ่นและประสิทธิภาพของการสร้างแบบจำลองที่ JDO นำมาใช้

ฉันใช้ Hibernate (การดำเนินการ JPA) และ JPOX (การดำเนินการ JDO) ในโครงการเดียวกัน JPOX ทำงานได้ดี แต่พบข้อผิดพลาดอย่างรวดเร็วในที่ซึ่งคุณสมบัติบางอย่างของ Java 5 นั้นไม่รองรับในเวลานั้น มีปัญหาในการเล่นที่ดีกับธุรกรรม XA ฉันสร้างสกีมาฐานข้อมูลจากวัตถุ JDO มันต้องการที่จะเชื่อมต่อกับฐานข้อมูลทุกครั้งที่น่ารำคาญถ้าการเชื่อมต่อ Oracle ของคุณไม่ทำงาน

จากนั้นเราเปลี่ยนเป็น Hibernate เราเล่นด้วยการใช้ JPA บริสุทธิ์สักครู่ แต่เราจำเป็นต้องใช้คุณสมบัติเฉพาะบางอย่างของไฮเบอร์เนตเพื่อทำแผนที่ การเรียกใช้รหัสเดียวกันในหลายฐานข้อมูลนั้นง่ายมาก ดูเหมือนว่าไฮเบอร์เนตจะแคชวัตถุอุกอาจหรือมีพฤติกรรมแคชแปลก ๆ ในบางครั้ง มีโครงสร้าง DDL ไม่กี่รายการที่ไฮเบอร์เนตไม่สามารถจัดการได้ดังนั้นจึงถูกกำหนดไว้ในไฟล์เพิ่มเติมที่เรียกใช้เพื่อเริ่มต้นฐานข้อมูล เมื่อฉันพบปัญหาไฮเบอร์เนตมักจะมีคนจำนวนมากที่พบปัญหาเดียวกันซึ่งทำให้ googling หาวิธีแก้ปัญหาได้ง่ายขึ้น ท้ายที่สุดดูเหมือนว่าไฮเบอร์เนตจะได้รับการออกแบบมาอย่างดีและน่าเชื่อถือ

ผู้เผชิญเหตุบางคนแนะนำให้ใช้ SQL กรณีการใช้งานนักฆ่าที่แท้จริงสำหรับการทำแผนที่วัตถุสัมพันธ์คือการทดสอบและพัฒนา ฐานข้อมูลที่สร้างขึ้นเพื่อจัดการปริมาณข้อมูลขนาดใหญ่มักมีราคาแพงและหรือติดตั้งได้ยาก พวกเขายากที่จะทดสอบด้วย มีฐานข้อมูล Java ในหน่วยความจำมากมายที่สามารถใช้ทดสอบ แต่โดยทั่วไปแล้วจะไม่มีประโยชน์สำหรับการผลิต ความสามารถในการใช้ฐานข้อมูลจริง แต่มีข้อ จำกัด จะเพิ่มประสิทธิภาพการพัฒนาและความน่าเชื่อถือของรหัส

ฉันสร้างตัวอย่าง WebApp ในเดือนพฤษภาคม 2012 ที่ใช้ JDO 3.0 และ DataNucleus 3.0 - ดูสิว่ามันสะอาดแค่ไหน: https://github.com/TorbenVesterager/BadAssWebApp

โอเคบางทีมันสะอาดเกินไปเล็กน้อยเพราะฉันใช้ POJO ทั้งฐานข้อมูลและไคลเอนต์ JSON แต่มันสนุก :)

PS: มีหมายเหตุประกอบ SuppressWarnings ไม่กี่ตัว (พัฒนาใน IntelliJ 11)