سؤال

في أي المجالات تتألق أو تفشل كل من هذه البنى البرمجية؟

ما هي المتطلبات الأساسية التي ستدفعك إلى اختيار أحدهما على الآخر؟

يرجى افتراض أن لديك مطورين متاحين يمكنهم تنفيذ تعليمات برمجية جيدة موجهة للكائنات بالإضافة إلى تطوير قاعدة بيانات جيدة.

يرجى أيضًا تجنب الحروب المقدسة :) جميع التقنيات الثلاثة لها إيجابيات وسلبيات، وأنا مهتم بالمكان الأنسب لاستخدام أي منها.

هل كانت مفيدة؟

المحلول

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

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

  • تتألق مولدات التعليمات البرمجية عند استخدام اللغات المكتوبة بشكل ثابت، لأنه يمكنك اكتشاف الأخطاء في وقت الترجمة بدلاً من وقت التشغيل.

  • تعتبر ORMs مثالية لأدوات التكامل، حيث قد تحتاج إلى التعامل مع أنظمة RDBMS ومخططات مختلفة على أساس التثبيت إلى التثبيت.قم بتغيير خريطة واحدة وسينتقل تطبيقك من العمل مع PeopleSoft على Oracle إلى العمل مع Microsoft Dynamics على SQL Server.

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

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

نصائح أخرى

سأضيف سنتي:

الإجراءات المخزنة

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

ORMs

  • تتيح لك التركيز فقط على المجال ولديك نهج أكثر "نقية" موجه نحو الكائنات في التطوير
  • تألق عندما يجب أن يكون تطبيقك متوافقًا مع قواعد البيانات المتقاطعة
  • تألق عندما يكون تطبيقك مدفوعًا في الغالب بالسلوك بدلاً من البيانات

مولدات الكود

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

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

يرجى الاطلاع على هذه المنشورتين الأخريين حول هذا الموضوع (الإجراءات الديناميكية SQL vs المخزنة مقابل ORM) لمزيد من المعلومات

SQL الديناميكية مقابل.الإجراءات المخزنة
ايهما افضل:استعلامات مخصصة، أو الإجراءات المخزنة؟

ORMs مقابل.الإجراءات المخزنة
لماذا يتم إنشاء SQL ذو معلمات بواسطة NHibernate بنفس سرعة الإجراء المخزن؟

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

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

لا توجد إجابة واحدة صحيحة، لكنني أميل أكثر نحو جانب ORM لأنني أعتقد أنه من المنطقي التفكير بعقلية "الكائن أولاً".

الإجراءات المخزنة

  • الايجابيات: يغلف رمز الوصول إلى البيانات وهو مستقل عن التطبيق
  • سلبيات: يمكن أن يكون خاصًا بـ RDBMS ويزيد من وقت التطوير

ORM

تسمح بعض ORMs على الأقل بالتخطيط للإجراءات المخزنة

  • الايجابيات: يلخص رمز الوصول إلى البيانات ويسمح بكتابة كائنات الكيان بطريقة خاصة بالمجال
  • سلبيات: الأداء المحتمل والقدرة على رسم الخرائط محدودة

رمز الجيل

  • الايجابيات: يمكن استخدامه لإنشاء تعليمات برمجية مستندة إلى proc مخزنة أو ORM أو مزيج من الاثنين معًا
  • سلبيات: قد يلزم الحفاظ على طبقة منشئ التعليمات البرمجية بالإضافة إلى فهم التعليمات البرمجية التي تم إنشاؤها

لقد نسيت خيارًا مهمًا يستحق فئة خاصة به:إطار رسم خرائط البيانات المختلطة مثل إيباتيس.

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top