متى تستخدم السبات/JPA/Toplink؟
https://stackoverflow.com/questions/122571
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أقوم حاليًا بإنشاء موقع ويب بسيط للغاية - حوالي 5 صفحات.السؤال هو ما إذا كان الأمر مبالغًا فيه ويستحق الوقت لدمج نوع من حلول تعيين قاعدة البيانات أو إذا كان من الأفضل استخدام JNDI القديم البسيط.ربما سيكون لدي عشرات الأشياء التي أحتاج إلى قراءتها/كتابتها من قاعدة البيانات.أعتقد أن لدي فهمًا أساسيًا لهذه التقنيات ولكن الأمر سيستغرق الكثير من الإشارة إلى الوثائق.هل هناك من واجه القرار من قبل؟
يحرر:عذرًا، كان ينبغي عليّ تحديد JNDI للبحث عن اتصال قاعدة البيانات وJDBC لإجراء العمليات.
المحلول
اجابة قصيرة:يعتمد ذلك على التعقيد الذي تريد دعمه.
اجابة طويلة:
بادئ ذي بدء، ORM (تعيين علائقي للكائنات - تعيين قاعدة البيانات كما تسميها -) وJNDI (تسمية Java وواجهات الدليل) هما شيئان مختلفان.
الأول، كما تعلم، يُستخدم لتعيين جداول قاعدة البيانات للفئات والكائنات.والثاني هو توفير آلية البحث عن الموارد، قد تكون DataSources، Ejb، قوائم الانتظار أو غيرها.
ربما يعني "JDBC".
والآن بالنسبة لسؤالك:إذا كان الأمر بهذه البساطة، فقد لا يكون من الضروري تنفيذ ORM.ستكون جداول الأرقام حوالي 5 - 10 على الأكثر، والعمليات بسيطة حقًا، على ما أعتقد.
ربما يكون استخدام JDBC العادي كافيًا.
إذا كنت تستخدم نمط DAO، فيمكنك تغييره لاحقًا لدعم استراتيجية ORM إذا لزم الأمر.
مثله:لنفترض أن لديك جدول الموظف
يمكنك إنشاء "Employee.java" مع كافة حقول قاعدة البيانات يدويًا (لا ينبغي أن يستغرق الأمر وقتًا طويلاً) وEmployeeDaO.java باستخدام أساليب مثل:
+findById( id ): Employee
+insert( Employee )
+update( Employee )
+delete( Employee )
+findAll():List<Employee>
والتنفيذ واضح تمامًا:
select * from employee where id = ?
insert into employee ( bla, bla, bla ) values ( ? , ? , ? )
update etc. etc
عندما (وإذا) أصبح تطبيقك معقدًا جدًا، فيمكنك تغيير تطبيق DAO.على سبيل المثال، في طريقة "التحديد"، يمكنك تغيير التعليمات البرمجية لاستخدام كائن ORM الذي يقوم بتنفيذ العملية.
public Employee selectById( int id ) {
// Commenting out the previous implementation...
// String query = select * from employee where id = ?
// execute( query )
// Using the ORM solution
Session session = getSession();
Employee e = ( Employee ) session.get( Employee.clas, id );
return e;
}
هذا مجرد مثال، في الحياة الواقعية، يمكنك السماح للمصنع المجرد بإنشاء ORM DAO، ولكن هذا أمر خارج عن الموضوع.النقطة المهمة هي أنه يمكنك البدء بشكل بسيط وباستخدام أنماط التصميم يمكنك تغيير التنفيذ لاحقًا إذا لزم الأمر.
بالطبع، إذا كنت ترغب في تعلم التكنولوجيا، فيمكنك البدء فورًا بطاولة واحدة.
يعتمد اختيار واحد أو آخر (حل ORM) بشكل أساسي على التكنولوجيا التي تستخدمها.على سبيل المثال، بالنسبة لـ JBoss أو غيرها من المنتجات مفتوحة المصدر، يعد Hibernate أمرًا رائعًا.إنه مفتوح المصدر، وهناك الكثير من الموارد التي يمكنك التعلم منها.ولكن إذا كنت تستخدم شيئًا يحتوي بالفعل على Toplink (مثل خادم تطبيقات Oracle) أو إذا كانت القاعدة مبنية بالفعل على Toplink، فيجب عليك البقاء مع إطار العمل هذا.
بالمناسبة، منذ أن اشترت Oracle BEA، قالوا إنهم يستبدلون Kodo (إطار عمل استمرارية الويب) بالرابط العلوي في ما يسمى الآن "Oracle Weblogic Application Server".
أترك لك بعض الموارد حيث يمكنك الحصول على مزيد من المعلومات حول هذا:
في كتاب "أنماط هندسة التطبيقات المؤسسية" هذا، يشرح مارتن فاولر مكان استخدام واحد أو آخر، إليك الكتالوج.ألقِ نظرة على الأنماط المعمارية لمصدر البيانات مقابل الأنماط المعمارية لمصدر البيانات.الأنماط السلوكية العلائقية للكائنات:
يعد DAO (كائن الوصول إلى البيانات) جزءًا من كتالوج أنماط J2EE الأساسية:
هذا هو البرنامج التعليمي المبدئي للإسبات:
الصفحة الرسمية لموقع توب لينك:
أخيرًا "أعتقد" أن التفكير الجيد في JPA هو أنه يمكنك تغيير مقدمي الخدمة مؤخرًا.
ابدأ بالبساطة ثم تطور.
آمل أن يساعد هذا.
نصائح أخرى
يبدو أنه سيكون مبالغة بالنسبة لتطبيق بسيط للغاية، خاصة إذا لم تكن لديك خطط للتوسع فيه على الإطلاق.ومع ذلك، يبدو أيضًا أنه قد يكون من المفيد استخدام تلك التي تحتوي على هذا التطبيق البسيط حتى يكون لديك فهم أفضل لكيفية عملها في المرة القادمة التي يكون لديك فيها شيء يمكنه استخدامها.
هل تقصد JDBC القديم العادي؟قد يكون المشروع الصغير فرصة جيدة لاختيار أحد أطر عمل ORM، خاصة إذا كان لديك الوقت.
بدون مزيد من المعلومات، من الصعب تقديم توصية بطريقة أو بأخرى.
قاعدتي الأساسية هي أنه إذا كان للقراءة فقط، فأنا على استعداد للقيام بذلك في JDBC، على الرغم من أنني أفضل استخدام مشروع Hibernate فارغ مع SQLQuery للاستفادة من تعيين نوع Hibernate.بمجرد أن أقوم بالكتابة، أستخدم وضع السبات لأنه من الأسهل بكثير تعيين بعض السمات ثم استدعاء الحفظ بدلاً من تعيين كل عمود على حدة.وعندما يتعين عليك البدء في التحسين لتجنب التحديثات على الكائنات التي لم تتغير، فمن الأفضل أن تستخدم OR/M وفحصها القذر.يعد التعامل مع علاقات المفاتيح الخارجية علامة أخرى على أنك تحتاج إلى تعيينها مرة واحدة ثم استخدام الحروف.سيتم تطبيق نفس المنطق على Toplink، على الرغم من أنه ما لم تتم إضافة شيء مثل HQL خلال السنوات الثلاث منذ أن استخدمته، فإن Hibernate سيكون أفضل بكثير لهذا النوع من الانتقال من SQL الخالص.ضع في اعتبارك أنه ليس عليك تعيين كل كائن/جدول، فقط تلك التي توجد بها ميزة واضحة.من خلال تجربتي، فإن معظم المشاريع التي لا تستخدم غرفة العمليات/الإدارة الحالية ينتهي بها الأمر إلى إنشاء وحدة جديدة، وهي فكرة سيئة.
ال أفضل طريقة تعلم ORM هي في مشروع صغير.البدء في هذا المشروع.
بمجرد أن تتقن الأمر، ستستخدم ORM في كل شيء.
لا يوجد شيء صغير جدًا بالنسبة لـ ORM.بعد أول مشروعين لك، ستجد أنه لا يمكنك العمل بأي طريقة أخرى.يعد تعيين ORM بشكل عام أكثر منطقية من أي طريقة عمل أخرى تقريبًا.
انظر إلى أدلة الروابط العلوية المختلفة هنا، فهي تحتوي على مقدمة وأمثلة وسيناريوهات وما إلى ذلك
