هل يستحق الأمر الجهد المبذول للانتقال من ملف تعيين السبات المصمم يدويًا إلى التعليقات التوضيحية؟

Question

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

إذن السؤال هو: هل يستحق كل هذا الجهد لإعادة بناء الكود الخاص بي لاستخدام التعليقات التوضيحية للإسبات؟هل سأكسب أي شيء، بخلاف أن أكون عصريًا وحديثًا؟هل سأفقد أيًا من عناصر التحكم التي أملكها في ملف الخرائط المشفر يدويًا الموجود لدي؟

والسؤال الفرعي هو كم سيكون من الجهد؟ أنا أحب قواعد البيانات الخاصة بي العجاف ويعني.لا يغطي التعيين سوى عشرة كائنات مجال، بما في ذلك مجموعتين، وبعض الفئات الفرعية، وحوالي 8 جداول.

شكرًا، عزيزي SOpedians، مقدمًا على آرائكم المستنيرة.

Answer 1

"إذا لم يكن مكسورًا - فلا تصلحه!"

أنا رجل من النوع القديم من POJO/POCO على أي حال، ولكن لماذا أغير إلى التعليقات التوضيحية فقط لكي أكون رائعًا؟على حد علمي، يمكنك القيام بمعظم الأشياء كتعليقات توضيحية، ولكن في بعض الأحيان يتم التعبير عن التعيينات الأكثر تعقيدًا بشكل أكثر وضوحًا بتنسيق XML.

Answer 2

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

على الجانب الآخر، ستفقد العرض الشامل الذي استخدمه ملف التعيين الخاص بك ليمنحك.

Answer 3

لقد قمت مؤخرًا بالأمرين معًا في مشروع ووجدت:

1. أفضل كتابة التعليقات التوضيحية على XML (يعمل بشكل جيد مع الكتابة الثابتة لـ Java، والإكمال التلقائي في IDE، وإعادة البناء، وما إلى ذلك).أحب رؤية الأشياء منسوجة معًا بدلاً من التنقل ذهابًا وإيابًا بين الكود وXML.
2. يشفر معلومات قاعدة البيانات في الفصول الدراسية الخاصة بك.بعض الناس يجدون ذلك مقززًا وغير مقبول.لا أستطيع أن أقول أنه أزعجني.يجب أن تذهب إلى مكان ما وسنقوم بإعادة بناء الحرب من أجل التغيير بغض النظر.
3. لقد ذهبنا بالفعل إلى التعليقات التوضيحية لـ JPA ولكن هناك بالتأكيد حالات لا تكون فيها التعليقات التوضيحية لـ JPA كافية، لذلك كان علينا استخدام إما التعليقات التوضيحية للإسبات أو التكوين للتعديل.
4. لاحظ أنه يمكنك بالفعل استخدام كل من التعليقات التوضيحية وملفات hbm.قد يكون هجينًا لطيفًا يحدد الجزء O في التعليقات التوضيحية والجزء R في ملفات hbm ولكنه يبدو وكأنه مشكلة أكثر مما يستحق.

Answer 4

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

Answer 5

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

Answer 6

يتم دعم جميع الميزات في XML وفي التعليقات التوضيحية.سيظل بإمكانك تجاوز التعليقات التوضيحية باستخدام إعلان XML.

أما بالنسبة للجهد، فأعتقد أن الأمر يستحق العناء حيث ستتمكن من رؤية كل شيء في مكان واحد وعدم التبديل بين الكود الخاص بك وملف xml (ما لم تكن تستخدم شاشتين بالطبع؛))

Answer 7

الشيء الوحيد الذي ستكسبه من استخدام التعليقات التوضيحية

ربما سأزعم أن هذا هو ال الشيء الذي تريد الاستفادة منه من استخدام التعليقات التوضيحية.نظرًا لأنك لا تحصل على أمان وقت التجميع باستخدام NHibernate، فهذا هو أفضل شيء تالي.

Answer 8

"إذا لم يكن مكسورًا - فلا تصلحه!"

@Macka - شكرًا، كنت بحاجة لسماع ذلك.وشكرا للجميع على إجاباتكم.

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

سأحاول تجربة التعليقات التوضيحية Hibernate أو JPA مع مشروع أخضر في وقت ما.لسوء الحظ، نادرًا ما أحصل على مشاريع جديدة مستقلة تمامًا.