Hibernate vs JPA vs JDO - إيجابيات وسلبيات كل منهما؟[مغلق]

Question

أنا على دراية بـ ORM كمفهوم، وقد استخدمت nHibernate منذ عدة سنوات لمشروع .NET؛ومع ذلك، لم أتابع موضوع ORM في Java ولم تتح لي الفرصة لاستخدام أي من هذه الأدوات.

ولكن، ربما تتاح لي الفرصة الآن للبدء في استخدام بعض أدوات ORM لأحد تطبيقاتنا، في محاولة للابتعاد عن سلسلة خدمات الويب القديمة.

أجد صعوبة في معرفة الفرق بين مواصفات JPA، وما تحصل عليه من مكتبة Hibernate نفسها، وما تقدمه JDO.

لذا، أفهم أن هذا السؤال مفتوح بعض الشيء، لكني كنت أتمنى الحصول على بعض الآراء حول:

• ما هي إيجابيات وسلبيات كل منها؟
• ماذا تقترح لمشروع جديد؟
• هل هناك شروط معينة عندما يكون من المنطقي استخدام إطار واحد مقابل الآخر؟

Answer 1

بعض الملاحظات:

• JDO وJPA كلاهما مواصفات وليس تطبيقات.
• الفكرة هي أنه يمكنك تبديل تطبيقات JPA، إذا قمت بتقييد التعليمات البرمجية الخاصة بك لاستخدام JPA القياسي فقط.(كما سبق لـ JDO.)
• يمكن استخدام السبات كأحد تطبيقات JPA.
• ومع ذلك، يوفر Hibernate واجهة برمجة تطبيقات أصلية، مع ميزات تفوق ميزات JPA.

IMO، أوصي بالإسبات.

---

كانت هناك بعض التعليقات/الأسئلة حول ما يجب عليك فعله إذا كنت يحتاج لاستخدام الميزات الخاصة بالإسبات.هناك طرق عديدة للنظر إلى هذا، لكن نصيحتي ستكون:

• إذا لم تكن قلقًا بشأن احتمال الارتباط بالمورد، فاختر بين Hibernate وتطبيقات JPA وJDO الأخرى مشتمل الملحقات المختلفة الخاصة بالبائع في عملية صنع القرار.

• إذا كنت قلقًا بشأن احتمال الارتباط بالمورد، ولا يمكنك استخدام JPA دون اللجوء إلى ملحقات خاصة بالبائع، فلا تستخدم JPA.(كما سبق لـ JDO).

في الواقع، ربما ستحتاج إلى المقايضة كم ثمن أنت قلق بشأن ارتباط البائع مقابل كم ثمن أنت بحاجة إلى تلك الملحقات الخاصة بالبائع.

وهناك عوامل أخرى أيضًا، مثل مدى معرفتك أنت / موظفيك بالتقنيات ذات الصلة، وكم ستكلف المنتجات عند الترخيص، ومن تؤمن بقصته حول ما سيحدث في المستقبل لـ JDO وJPA.

Answer 2

تأكد من تقييم تطبيق DataNucleus لـ JDO.لقد بدأنا باستخدام Hibernate لأنه بدا شائعًا جدًا ولكن سرعان ما أدركنا أنه ليس حلاً ثابتًا شفافًا بنسبة 100٪.هناك الكثير من التحذيرات والوثائق مليئة بـ "إذا كان لديك هذا الموقف، فيجب عليك كتابة التعليمات البرمجية الخاصة بك مثل هذا" مما أدى إلى إبعاد متعة النمذجة والبرمجة بحرية كيفما أردنا.JDO لديها أبداً جعلني أضبط الكود أو النموذج الخاص بي حتى "يعمل بشكل صحيح".يمكنني فقط تصميم وبرمجة POJOs بسيطة كما لو كنت سأستخدمها "في الذاكرة" فقط، ومع ذلك يمكنني الاحتفاظ بها بشفافية.

الميزة الأخرى لـ JDO/DataNucleus عبر السبات هي أنه لا يحتوي على كل انعكاس وقت التشغيل وهو أكثر كفاءة في الذاكرة لأنه يستخدم تحسين رمز البايت لوقت البناء (ربما أضف ثانية واحدة إلى وقت البناء الخاص بك لمشروع كبير) بدلاً من ذلك من نمط الوكيل المدعوم بانعكاس وقت تشغيل السبات.

شيء آخر قد تجده مزعجًا مع Hibernate هو أن الإشارة التي لديك إلى ما تعتقد أنه الكائن...غالبًا ما يكون "وكيلًا" للكائن.بدون الاستفادة من تحسين كود البايت، يكون نمط الوكيل مطلوبًا للسماح بالتحميل عند الطلب (أي.تجنب سحب الرسم البياني للكائن بالكامل عند سحب كائن من المستوى الأعلى).كن مستعدًا لتجاوز يساوي ورمز التجزئة لأن الكائن الذي تعتقد أنك تشير إليه غالبًا ما يكون مجرد وكيل لذلك الكائن.

فيما يلي مثال على الإحباطات التي ستواجهها مع Hibernate والتي لن تحصل عليها مع JDO:

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

إذا كنت تحب البرمجة باستخدام "الحلول البديلة"، فبالتأكيد فإن Hibernate هو الخيار المناسب لك.إذا كنت تقدر التطوير النظيف والصافي والموجه نحو الكائنات والذي يعتمد على النماذج حيث تقضي كل وقتك في النمذجة والتصميم والبرمجة ولا شيء منها في الحلول القبيحة، فاقض بضع ساعات في التقييم JDO/DataNucleus.سيتم سداد الساعات المستثمرة ألف مرة.

تحديث فبراير 2017

لبعض الوقت الآن، تطبق DataNucleus معيار استمرارية JPA بالإضافة إلى معيار استمرارية JDO، لذلك يجب أن يكون نقل مشاريع JPA الحالية من Hibernate إلى DataNucleus مباشرًا جدًا ويمكنك الحصول على جميع المزايا المذكورة أعلاه من DataNucleus مع تغيير بسيط جدًا في التعليمات البرمجية ، لو اي.لذا فيما يتعلق بالسؤال، فإن اختيار معيار معين، JPA (RDBMS فقط) مقابل JDO (RDBMS + No SQL + ODBMSes + أخرى)، يدعم DataNucleus كليهما، ويقتصر السبات على JPA فقط.

أداء تحديثات قاعدة بيانات السبات

هناك مشكلة أخرى يجب مراعاتها عند اختيار ORM وهي كفاءة آلية التحقق القذرة الخاصة بها - والتي تصبح مهمة جدًا عندما تحتاج إلى إنشاء SQL لتحديث الكائنات التي تغيرت في المعاملة الحالية - خاصة عندما يكون هناك الكثير من الكائنات.يوجد وصف فني مفصل لآلية التحقق القذرة في Hibernate في إجابة SO هذه:إدراج JPA مع السبات بطيء جدًا

Answer 3

لقد قمت مؤخرًا بتقييم واختيار إطار استمرارية لمشروع جافا وكانت النتائج التي توصلت إليها كما يلي:

ما أراه هو أن الدعم لصالح JDO هو في المقام الأول:

• يمكنك استخدام مصادر بيانات غير SQL، وdb4o، وhbase، وldap، وbigtable، وcouchdb (المكونات الإضافية لـ cassandra) وما إلى ذلك.
• يمكنك التبديل بسهولة من مصدر بيانات SQL إلى مصدر بيانات غير SQL والعكس صحيح.
• لا توجد كائنات وكيل وبالتالي أقل ألمًا فيما يتعلق بتطبيقات hashcode() وequals()
• يتطلب المزيد من POJO وبالتالي حلول بديلة أقل
• يدعم المزيد من أنواع العلاقات والحقول

والدعم لصالح JPA هو في المقام الأول:

• اكثر شهرة
• جدو مات
• لا يستخدم تحسين bytecode

أرى الكثير من المنشورات المؤيدة لـ JPA من مطوري JPA الذين من الواضح أنهم لم يستخدموا JDO/Datanucleus ويقدمون حججًا ضعيفة لعدم استخدام JDO.

أرى أيضًا الكثير من المنشورات من مستخدمي JDO الذين انتقلوا إلى JDO وأصبحوا أكثر سعادة نتيجة لذلك.

فيما يتعلق بكون JPA أكثر شيوعًا، يبدو أن هذا يرجع جزئيًا إلى دعم موردي RDBMS بدلاً من كونه متفوقًا تقنيًا.(يبدو لي وكأنه VHS/Betamax).

من الواضح أن JDO وتنفيذها المرجعي Datanucleus لم يمت، كما يتضح من اعتماد Google له لـ GAE والتطوير النشط على الكود المصدري (http://sourceforge.net/projects/datanucleus/).

لقد رأيت عددًا من الشكاوى حول JDO بسبب تحسين الرمز الثانوي، لكن لا يوجد تفسير حتى الآن لسبب كونه سيئًا.

في الواقع، في عالم أصبح مهووسًا بشكل متزايد بحلول NoSQL، يبدو JDO (وتنفيذ نواة البيانات) رهانًا أكثر أمانًا.

لقد بدأت للتو في استخدام JDO/Datanucleus وقمت بإعداده حتى أتمكن من التبديل بسهولة بين استخدام db4o وmysql.من المفيد للتطوير السريع استخدام db4o ولا داعي للقلق كثيرًا بشأن مخطط قاعدة البيانات وبعد ذلك، بمجرد استقرار المخطط للنشر في قاعدة البيانات.أشعر أيضًا بالثقة أنه في وقت لاحق، يمكنني نشر كل/جزء من تطبيقي على GAE أو الاستفادة من التخزين الموزع/تقليل الخريطة على غرار hbase /hadoop / cassandra دون الحاجة إلى الكثير من إعادة البناء.

لقد وجدت أن العقبة الأولية للبدء في استخدام Datanucleus صعبة بعض الشيء - من الصعب بعض الشيء الدخول إلى الوثائق الموجودة على موقع datanucleus - ليس من السهل متابعة البرامج التعليمية كما كنت أتمنى.بعد قولي هذا، تعد الوثائق الأكثر تفصيلاً حول واجهة برمجة التطبيقات ورسم الخرائط جيدة جدًا بمجرد تجاوز منحنى التعلم الأولي.

الجواب هو أن الأمر يعتمد على ما تريد.أفضل أن يكون لدي كود أنظف، وعدم قفل البائع، وأكثر توجهاً نحو pojo، وخيارات nosql أكثر شيوعًا.

إذا كنت تريد الشعور الدافئ بأنك تفعل نفس الشيء الذي تفعله غالبية المطورين/الأغنام الآخرين، فاختر JPA/hibernate.إذا كنت ترغب في الريادة في مجال عملك، فاختبر قيادة JDO/Datanucleus واتخذ قرارك بنفسك.

Answer 4

ماذا تقترح لمشروع جديد؟

أود أن أقترح لا!استخدم Spring DAO JdbcTemplate معا مع StoredProcedure, RowMapper و RowCallbackHandler بدلاً من.

تجربتي الشخصية مع Hibernate هي أن الوقت الذي تم توفيره مقدمًا يتم تعويضه بالأيام التي لا نهاية لها والتي ستقضيها في محاولة فهم المشكلات وتصحيح الأخطاء مثل سلوك التحديث المتتالي غير المتوقع.

إذا كنت تستخدم قاعدة بيانات علائقية، فكلما اقتربت التعليمات البرمجية الخاصة بك منها، زادت قدرتك على التحكم.تسمح طبقة DAO الخاصة بـ Spring بالتحكم الدقيق في طبقة التعيين، مع إزالة الحاجة إلى التعليمات البرمجية المعيارية.كما أنه يتكامل مع طبقة معاملات Spring مما يعني أنه يمكنك بسهولة إضافة (عبر AOP) سلوك معاملات معقد دون أن يتطفل هذا على التعليمات البرمجية الخاصة بك (بالطبع، يمكنك الحصول على هذا باستخدام Hibernate أيضًا).

Answer 5

JDO مات

JDO لم يمت في الواقع لذا يرجى التحقق من الحقائق الخاصة بك.تم إصدار JDO 2.2 في أكتوبر 2008 JDO 2.3 قيد التطوير.

تم تطوير هذا بشكل علني، تحت أباتشي.إصدارات أكثر من JPA، ولا تزال مواصفات ORM الخاصة بها متقدمة حتى على الميزات المقترحة لـ JPA2

Answer 6

تتمتع JDO بميزات متقدمة مقارنة بـ JPA http://db.apache.org/jdo/jdo_v_jpa.html

Answer 7

أنا أستخدم JPA (تنفيذ OpenJPA من Apache والذي يعتمد على قاعدة بيانات KODO JDO التي يزيد عمرها عن 5 سنوات وهي سريعة/موثوقة للغاية).IMHO أي شخص يطلب منك تجاوز المواصفات يقدم لك نصيحة سيئة.لقد أضعت الوقت وحصلت على المكافأة بالتأكيد.باستخدام JDO أو JPA، يمكنك تغيير البائعين بأقل قدر من التغييرات (يحتوي JPA على تعيين orm لذلك نحن نتحدث عن أقل من يوم لتغيير البائعين).إذا كان لديك أكثر من 100 طاولة كما أفعل، فهذا أمر ضخم.بالإضافة إلى أنك تحصل على تخزين مؤقت مدمج مع عمليات إخلاء ذاكرة التخزين المؤقت على مستوى المجموعة، وكل ذلك جيد.يعتبر SQL/Jdbc مناسبًا للاستعلامات عالية الأداء ولكن المثابرة الشفافة أفضل بكثير لكتابة الخوارزميات وإجراءات إدخال البيانات.ليس لدي سوى حوالي 16 استعلام SQL في نظامي بالكامل (50 ألفًا + سطرًا من التعليمات البرمجية).

Answer 8

أي شخص يقول أن JDO قد مات هو مروج FUD وهم يعرفون ذلك.

JDO على قيد الحياة وبصحة جيدة.لا تزال المواصفات أكثر قوة ونضجًا وتقدمًا من JPA الأصغر حجمًا والمقيد.

إذا كنت تريد أن تقتصر على ما هو متاح في معيار JPA فقط، فيمكنك الكتابة إلى JPA واستخدام DataNucleus كتطبيق عالي الأداء وأكثر شفافية من تطبيقات JPA الأخرى.بالطبع تقوم DataNucleus أيضًا بتنفيذ معيار JDO إذا كنت تريد المرونة والكفاءة في النمذجة التي توفرها JDO.

Answer 9

لقد بحثت في هذا بنفسي ولم أجد فرقًا قويًا بين الاثنين.أعتقد أن الاختيار الكبير هو في أي تطبيق تستخدمه.لنفسي كنت أفكر في نواة البيانات النظام الأساسي لأنه تطبيق حيادي لمخزن البيانات لكليهما.

Answer 10

لقد استخدمت Hibernate (تنفيذ JPA) وJPOX (تنفيذ JDO) في نفس المشروع.عملت JPOX بشكل جيد، ولكنها واجهت أخطاء بسرعة إلى حد ما، حيث لم تكن تدعم بعض ميزات لغة Java 5 في ذلك الوقت.واجهت مشاكل في اللعب بشكل جيد مع معاملات XA.كنت أقوم بإنشاء مخطط قاعدة البيانات من كائنات JDO.لقد أراد الاتصال بقاعدة بيانات في كل مرة وهو أمر مزعج إذا كان اتصال Oracle الخاص بك لا يعمل.

ثم تحولنا إلى السبات.لقد تعاملنا مع استخدام JPA النقي لفترة من الوقت، لكننا كنا بحاجة إلى استخدام بعض ميزات السبات المحددة لإجراء التعيين.يعد تشغيل نفس الكود على قواعد بيانات متعددة أمرًا سهلاً للغاية.يبدو أن السبات يقوم بتخزين الكائنات مؤقتًا بقوة أو يكون لديه سلوك تخزين مؤقت غريب في بعض الأحيان.هناك عدد قليل من بنيات DDL التي لا يمكن لـ Hibernate التعامل معها ولذلك يتم تعريفها في ملف إضافي يتم تشغيله لتهيئة قاعدة البيانات.عندما أواجه مشكلة السبات، غالبًا ما يواجه العديد من الأشخاص نفس المشكلة مما يجعل البحث عن الحلول أسهل على Google.أخيرًا، يبدو أن Hibernate مصمم جيدًا وموثوق به.

اقترح بعض المستجيبين الآخرين استخدام SQL فقط.حالة الاستخدام القاتل الحقيقي لرسم الخرائط العلائقية للكائنات هي الاختبار والتطوير.عادة ما تكون قواعد البيانات التي تم إنشاؤها للتعامل مع كميات كبيرة من البيانات باهظة الثمن أو يصعب تثبيتها.من الصعب اختبارها.هناك الكثير من قواعد بيانات Java الموجودة في الذاكرة والتي يمكن استخدامها للاختبار، ولكنها عادةً ما تكون غير مجدية للإنتاج.ستؤدي القدرة على استخدام قاعدة بيانات حقيقية، ولكن محدودة، إلى زيادة إنتاجية التطوير وموثوقية التعليمات البرمجية.

Answer 11

لقد قمت بإنشاء نموذج WebApp في مايو 2012 يستخدم JDO 3.0 وDataNucleus 3.0 - ألقِ نظرة على مدى نظافته:https://github.com/TorbenVesterager/BadAssWebApp

حسنًا، ربما يكون الأمر نظيفًا بعض الشيء، لأنني أستخدم POJOs لكل من قاعدة البيانات وعميل JSON، ولكنه ممتع :)

ملاحظة:يحتوي على عدد قليل من التعليقات التوضيحية لـ SuppressWarnings (تم تطويرها في IntelliJ 11)