JDO vs JPA لـ Java على Google App Engine

https://stackoverflow.com/questions/1418219

07-07-2019
|

سؤال

أرغب في تطوير مشروعي على Google App Engine باستخدام Struts2.بالنسبة لقاعدة البيانات لدي خياران JPA وJDO.هل يا رفاق من فضلكم تقترحون علي ذلك؟كلاهما جديد بالنسبة لي وأحتاج إلى تعلمهما.لذلك سوف أركز على واحد بعد ردودكم.

شكرًا.

المحلول

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

نصائح أخرى

وو/ J مجموعة جوجل GAE لديها العديد من المشاركات حول هذا الشيء. فما استقاموا لكم فاستقيموا القيام بعملية بحث على هناك والنظر في آراء الناس. سوف تحصل على رسالة مختلفة جدا من الآراء الواردة أعلاه. تركز أيضا على حقيقة أن جداول كبيرة ليس RDBMS. استخدام الأداة المناسبة لهذا المنصب

ورأيت للتو هذه المقارنة بين النقابة وJDO التي كتبها DataNucleus أنفسهم: - http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html وفتحت عيني.

وأنا مستخدم سعيدة JDO. مواكبة العمل الجيد من الرجال.

الأشخاص الذين يزعمون أن JDO قد مات لا يخلو من الجدارة.إليك ما قرأته في كتاب Pro EJB 3 Java Persistence API:"بعد ذلك بوقت قصير، أعلنت شركة Sun أن JDO سيتم تحويله إلى وضع صيانة المواصفات وأن Java Persistence API سوف يستمد من كل من JDO وبائعي الثبات الآخرين ويصبح المعيار الوحيد المدعوم من الآن فصاعدًا."المؤلف مايك كيث هو قائد المواصفات المشتركة في EJB3.بالطبع هو مؤيد كبير لـ JPA، لكني أشك في أنه متحيز بما يكفي للكذب.

صحيح أنه عندما تم نشر الكتاب، كان معظم البائعين الرئيسيين متحدين خلف JPA بدلاً من JDO، على الرغم من أن JDO لديها ميزات تقنية أكثر تقدمًا من JPA.ليس من المستغرب أن اللاعبين الكبار في عالم EE مثل IBM/Oracle هم أيضًا من كبار بائعي RDBMS.يستخدم عدد أكبر من العملاء RDMBS أكثر من غير RDMBS في مشاريعهم.كانت JDO تحتضر حتى أعطتها GAE دفعة كبيرة.وهذا أمر منطقي لأن مخزن بيانات GAE ليس قاعدة بيانات علائقية.لا تعمل بعض ميزات JPA مع bigtable مثل استعلامات التجميع، واستعلامات الانضمام، والعلاقات المملوكة للعديد من الأطراف.راجع للشغل، يدعم GAE JDO 2.3 بينما يدعم فقط JPA 1.0.سأوصي بـ JDO إذا كانت GAE هي النظام الأساسي السحابي الذي تستهدفه.

لسجل، هو محرك تطبيقات جوجل (GAE)، لذلك لعبنا مع يحكم جوجل ليس مع قواعد أوراكل / أحد

وبموجب ذلك، النقابة ليست مناسبة للGAE، فمن غير مستقرة وأنها لا تعمل كما هو متوقع. لا جوجل مستعدة لدعم ذلك، ولكن الحد الأدنى.

وعن الجزء الآخر، JDO غير مستقر تماما في GAE وهو (في تمديد بعض) موثقة جيدا من قبل جوجل.

ومع ذلك، لا تنصح Google أي منها.

http://code.google.com/appengine/docs/ جافا / مخزن البيانات / overview.html نظرة

وAPI ذات المستوى المنخفض سوف تعطي أفضل أداء وGAE هو كل شيء عن الأداء.

http://gaejava.appspot.com/

وعلى سبيل المثال، إضافة 10 كيان

<اقتباس فقرة>

وبيثون: 68ms

وJDO: 378ms

وجافا الأصلية: 30ms

في سباق بين JDO مقابل JPA يمكن إلا أن نتفق مع الملصقات datanucleus.

وأولا وقبل كل شيء، وأيضا الأهم من ذلك، ملصقات datanucleus يعرفون ماذا يفعلون. فهي بعد كل تطوير مكتبة الثابتة ومعتادا على نماذج البيانات غير العلائقية، على سبيل المثال طاولة كبيرة. أنا متأكد من أن معرف كانت مطور لالسبات هنا، وقال انه كان يقول: "كل افتراضاتنا عند بناء المكتبات الأساسية لدينا هي المقرونة بإحكام إلى نموذج العلائقي، ليست الأمثل السبات لGAE"

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

من وجهة نظر البرمجة موقف، وذلك باستخدام واجهات برمجة التطبيقات JDO هو خيار أفضل بكثير، لأنك المساس المفهوم أقل كثيرا. يمكنك التبديل، نظريا على أي نموذج بيانات من رغبتك، وفرت مزود استخدام تدعم قاعدة البيانات الأساسية. (وفي الواقع نادرا ما تحقيق هذا المستوى الرفيع من transparancy، لأنك سوف تجد نفسك وضع المفاتيح الأساسية الخاصة بك على وجوه GAE وسوف يتم ربط نفسك لمزود قاعدة بيانات محددة، مثل جوجل). فإنه لا يزال من الأسهل على الهجرة بالرغم من ذلك.

وثالثا، يمكنك استخدام السبات، والكسوف وصلة، وحتى الربيع مع GAE. جوجل يبدو أن بذلت جهدا كبيرا من أجل السماح لك استخدام أطر كنت تستخدم لبناء التطبيقات الخاصة بك على. ولكن ما يدرك الناس عندما بناء تطبيقات GAE بها كما لو كانت تعمل على RDBMS هي أنها بطيئة. الربيع على GAE بطيء. يمكنك جوجل فيديو جوجل IO على هذا الموضوع لمعرفة أنه هو الصحيح.

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

في كل هذا، لا بد لي من أشبع أن هناك شيء واحد مهم جدا الذهاب لنقابة الصحفيين. وهذا هو Guice ودعم مناسب من أجل نقابة الصحفيين. يبدو أن جوجل لم يكن الذكية كالمعتاد في هذه النقطة وهي المحتوى، في الوقت الراهن في عدم دعم JDO. ما زلت أعتقد أنهم يستطيعون ذلك، وفي نهاية المطاف Guice تبتلع JDO كذلك، ... أو ربما لا.

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

ما أعتقد أنه أمر فظيع في الاستخدام JDO في وقت كتابة هذا التقرير، كان هذا هو بائع التنفيذ الوحيد Datanucleus ومن عيوب ذلك قلة المنافسة مما يؤدي إلى العديد من المشكلات مثل:

وثائق ليست مفصلة للغاية حول بعض الجوانب مثل extensions
عادةً ما تحصل على ردود ساخرة من المؤلفين مثل (هل قمت بفحص السجلات؟ربما يكون هناك سبب لوجودهم) وردود مزعجة من هذا القبيل
لن تحصل على إجابة لسؤالك في فترة زمنية مفيدة، وأحيانًا إذا حصلت على إجابة في أقل من 7 أيام، فيجب أن تعتبر نفسك محظوظًا، حتى هنا StackOverflow

أتمنى دائمًا أن يبدأ شخص ما في تنفيذ JDO المواصفات نفسها، ربما سيقدمون شيئًا أكثر ونأمل أكثر حر الاهتمام بالمجتمع وعدم الاهتمام دائمًا بالحصول على أموال مقابل الدعم، وعدم قول ذلك Datanucleus المؤلفون يهتمون فقط بالدعم التجاري، لكني أقول فقط.

أنا شخصيا أعتبر Datanucleus المؤلفون ليس لديهم أي التزام على الإطلاق بذلك Datanucleus نفسها ولا مجتمعها.يمكنهم إسقاط المشروع بأكمله في أي وقت ولا يمكن لأحد أن يحكم عليهم، فهذا جهدهم وممتلكاتهم الخاصة.ولكن يجب أن تعرف ما أنت مقبل عليه.كما ترى، عندما يبحث أحد المطورين عن إطار عمل لاستخدامه، لا يمكنك معاقبة مؤلف إطار العمل أو إصدار أمر له، ولكن من ناحية أخرى، تحتاج إلى إنجاز عملك!إذا كان لديك الوقت لكتابة هذا الإطار، فلماذا تبحث عنه في المقام الأول؟!

على الجانب الآخر، JDO في حد ذاته لديه بعض التعقيدات مثل دورة حياة الكائنات والأشياء التي ليست بديهية وشائعة جدًا (على ما أعتقد).

يحرر:الآن أعرف أيضًا JPA يفرض آلية دورة حياة الكائن، لذلك يبدو أنه لا مفر من التعامل مع حالات دورة حياة الكيانات المستمرة إذا كنت ترغب في استخدام واجهة برمجة تطبيقات ORM القياسية (أي. JPA أو JDO)

أكثر ما يعجبني فيه JDO هي القدرة على العمل مع أي نظام لإدارة قواعد البيانات دون بذل جهد كبير.

ومن المقرر

وGAE / J لإضافة MYSQL قبل نهاية هذا العام.

وJPA هو الطريق للذهاب لأنه يبدو أن دفعت باعتباره API موحدة وحصلت مؤخرا زخما في EJB3.0 .. JDO يبدو أنه فقد البخار.

لا

استخدم تشييء، لأن أرخص (استخدام موارد أقل)، وأسرع. لمعلوماتك: http://paulonjava.blogspot.mx/2010/12/tuning مرور Google-appengine.html

<اقتباس فقرة>

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

وتشييء يتيح لك الاستمرار واسترجاعها، وحذف، والاستعلام الأجسام كتبته بنفسك.

@Entity
class Car {
    @Id String vin; // Can be Long, long, or String
    String color;
}

ofy().save().entity(new Car("123123", "red")).now();
Car c = ofy().load().type(Car.class).id("123123").now();
ofy().delete().entity(c);

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow