ليلة سعيدة يا هبر.
هذه المقالة محاولة لتسهيل البحث عن الأشخاص الذين يبدأون في وضع السبات ويواجهون نفس السؤال الذي يواجهني - وهو
كيفية الكتابة بشكل صحيح على هذه الأداة . (سيكون هذا مفيدًا بشكل خاص للمبرمجين الذين يأتون إلى java من اللغات المكتوبة بشكل ضعيف). لن يكون هناك كود ، سيكون هناك مبادئ أساسية حول كيفية استخدام هذه التكنولوجيا بشكل منتج. كل شيء مكتوب تحت الخفض هو IMHO الخاص بي ، وليس المطالبة بالحل الوحيد الممكن للمشكلة.
هكذا
إبداء تحفظ على الفور أن تجربتي كانت مع
Spring Data JPA .
نظرًا لأن Hibernate هو إطار عمل للمؤسسة ، فمن الصعب العثور على أمثلة للكود عليها أعمق من CRUD العادية. هذه الحقيقة تعقد على نحو خطير فهم كيفية الكتابة في Hiber ، وكيف تخيل مطورو الإطار أنفسهم رمزًا جيدًا - كنتيجة لذلك ، كان علي التفكير في هذه المسألة بنفسي. أنا متأكد من أنني لست وحدي.
@
أول ما يمكنك ملاحظته هو أنه لا توجد قاعدة بيانات تجريدية. في حالة السبات ، تم القيام بكل شيء للحصول على تحكم كامل في قاعدة البيانات في الكود (يمكنك إدارة Google Entity Management). قاعدة البيانات الخاصة بك هي كائنات المجال التي تؤدي وظيفة التخزين غبي تقريبا. ومن هنا قاعدة مهمة: لا تستخدمها في أي شيء سوى التخزين. لا ينبغي أن تؤدي وظائف DTO التي تقبل إدخال المستخدم ، ويجب ألا تكون بمثابة شاشة عرض أثناء التسلسل. لديهم الكفوف.
لا يصدق ولكن صحيحبشكل عام ، من المدهش ألا أرى في الجزء التعليمي من الإنترنت (بما في ذلك اللغة الإنجليزية) مثالًا على استخدام فصول إضافية للتسلسل ، على سبيل المثال ، في json. من قال من قبل إنه إذا كان لديك خدمة REST ، فلا داعي للقلق بشأن فئات العرض؟)
نعم ، وليس بالنسبة لـ REST ، يوحي الحدس بنبرة جيدة ، أنه لن يقدم للعميل سوى مجموعة البيانات التي يحتاجها ، في حين أن جميع البيانات جاهزة (ولم يكن مضطرًا للاتصال بالأخطاء على العميل للتهيئة البطيئة).
@
هذا يعني القاعدة التالية - يجب ألا يهتموا بتنسيق الاستخدام. سواء كنا بحاجة إلى قائمة بالمنتجات (حيث سيكون الاسم والوصف فقط) أو صفحة المنتج (مع الصور والتعليقات) - سيتلقى العميل في إحدى الحالات
List من
SimpleProductViewer (id, name, description) وفي الحالة الأخرى
ExtendedProductViewer (id, name, description, List(photos), List(reviews), rating) ، والتي سيتم إنشاؤها في أساليب فئة
ProductService واستخدام فئات المجال
فقط كمصدر للبيانات.
نفس الشيء مع المدخلات. هذا هو Java ، لا بأس في القيام بـ DTO مع الحقول المختلفة لكل حالة :)
على سبيل المثال ، سأزيد من قاعدة الفصل لنطاق المنتج الذي تم اختراقه. ما لدينا بالفعل:
- المنتج (المجال)
- عارض (فصول لعرض العميل للمعلومات ، يمكن أن يكون أي رقم)
- Dto (فصول الحصول على المعلومات يمكن أن تكون أيضًا أي رقم)
- مستودع (لتلقي البيانات)
- خدمة (أو مدير) - صندوق أسود لمنطق الأعمال غير المنضبط ، والذي يجمع بين جميع النقاط السابقة.
@
يبدو لي (يبدو) أن Java Enterprise غير مُحسّن للغاية (يمكن رؤية ذلك بالفعل بناءً على طلب السبات وحقيقة أن OOP (السبات) قد استحوذ على الغطاء لإدارة كيانات قاعدة البيانات). لذلك ، أعتقد أن الشيء الرئيسي في هذا السياق هو مراسلة الكود لأفكار مطوري الإطار ، وليس الإستراتيجية المثلى.
@
إذا نظرت إلى مجالات السبات بهذه الطريقة (تخزين البيانات فقط) ، يبدو أن
@ManyToOne هو آلية لا يتم استخدامها كثيرًا وتطبق فقط على الجداول المعتمدة بالكامل - الصور والتعليقات والتعليقات. من حيث المبدأ ، هذا أمر طبيعي - في رأيي ، ليس من الضروري تمديد تأثيرها على الجداول الأساسية لقاعدة البيانات الخاصة بك.
تلخيص
- استخدم المجال فقط لتخزين البيانات ، فمن المستحسن أن يتم احتواء خصائص الفئة في جدول قاعدة البيانات الهدف ، أي أنه لا يوجد شيء لا لزوم له (تمليه منطق الأعمال).
- لا حاجة لمحاولة توسيع المجال - تمديد فئات العرض ، واستخدام فئات المجال فقط كموفر للبيانات.
- لا تخف من إنتاج نفس النوع من الفصول - فهم أكثر مرونة وسهولة الاستخدام. الحد الأقصى الذي يمكن القيام به لتقليل مقدار التعليمات البرمجية هو الميراث من المجال.
- لا تطارد التحسين. بالنسبة إلى أولاد جافا ، هذا ليس مهمًا ، على الرغم من أن كل هذا يتوقف بالطبع على السياق.
شيء من هذا القبيل.