اذهب إلى المحتوى

السؤال

نشر

سلام وعليكم,

اثناء متابعة لأحد الدورات في  udemy لبناء متجر الكتروني لم يقم المدرب بأنشاء نموذج(model) لكل جدول في قاعدة البيانات كما فعلنا في دورة تطوير تطبيقات الويب بphp , فقط قام بأنشاء نموذج خاص بuser و admin.

مثلا عند اضافة منتوج جديد :
في اكادمية حسوب انشئنا جدول خاص بالمنتجات (create_products_table) و نموذج  خاص بالمنتجات (Product) مع تعريف العلاقات و في ProductController نكتب:

public function newProduct(Request $request)
{
	$product = new Product();
	$product->title = $request->title;
	$product->save();
}

اما في دورة

اقتباس

 udemy لبناء متجر الكتروني

اثناء اضافة منتج قام بانشاء فقط جدول خاص بالمنتجات (create_products_table) و في   ProductController

public function newProducts(Request $request)
{
	$date = array();
	$date['title'] = $request->title;
	DB::table('products')->insert($data);
}

 

---------------------

فمالفرق بين الطريقتين , وما الطريقة التي يجب ان استخدمها ام انا حر في الاختيار؟

Recommended Posts

  • 0
نشر

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

قبل الاعتماد على لارافل لم يكن يستخدم النماذج أصلا وكانت جداول قاعدة البيانات هي النماذج الأساسية وكان يتم كتابة استعلامات SQL مباشرة ضمن شيفرات PHP، وفيما بعد ظهر مفهوم PDO وأصبحت البرمجة غرضية التوجه في بناء الاستعلامات هي الأساس و مع ظهور لارافل أصبحنا نتعامل مع جدول البيانات بطريقة أفضل و أكثر تحكما و بالاعتماد على النماذج Models عن طريق Eloquent، والتي سهلت بناء و إدارة قواعد البينات بشكل كبير.

إن استخدام النماذج كما في دورة الأكاديمية تعطينا أسلوب أفضل في التعامل مع الجداول حسب Active Records Pattern و 

يعد Active Record حلاً جيدًا لمعالجة كيان واحد بطريقة CRUD - أي إنشاء كيان جديد بخصائص مسندة القيم ثم حفظه في قاعدة بيانات أو تحميل سجل من قاعدة بيانات أو حذفه.

ميزات Eloquent مثل التحقق المتسخ dirty checking (لإرسال SQL UPDATE فقط للحقول التي تم تغييرها) ، ونموذج الأحداث model events (على سبيل المثال لإرسال التنبيهات الإدارية أو تحديث عدادات الإحصائيات عندما يقوم شخص ما بإنشاء حساب جديد) ،السمات traits (الطوابع الزمنية ، المحذوفات الناعمة ، سماتك المخصصة) (timestamps, soft deletes, your custom traits) التحميل الشغوف / البطيء eager/lazy loading إلخ بالإضافة لـ التحقق من صحة وإدارة العلاقات validation, managing relations.

ولكن استخدام هذا الأسلوب يؤثر على أداء التطبيق (تطبيق متوسط لكبير الحجم وعدد زوار كبير) لأنه يقوم ببناء الكثير من الأغراض و حجز الذاكرة Ram أثناء التنفيذ.

إن استخدام Laravel DB methods هو أفضل في مصفوفات البيانات ، للتقارير ، لمعالجة الدُفعات (datagrids, for reports, for batch processing) لأنها تتعامل مع بيانات كبيرة الحجم بأداء أفضل.

نستخدم كلا الأسلوبين حتى لو في نفس التطبيق (المشروع) نميل لأحد الأسلوبين حسب فهمنا لكيفية التعامل مع البيانات و حجمها ومدى تأثيرها على الأداء.

  • 0
نشر

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

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

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

  • 0
نشر

هناك طريقتين للتعامل مع قاعدة البيانات إما عن طريق ال eloquent orm و هي نفس الطريقة التي قد إستخدمناها في الدورات او عن طريق ال query builder.

ال orm هو رابط الكائنات بالعلاقات و يعتمد بشكل أساسي على نماذج و الربط بينها عن طريق العلاقات وكل نموذج يتم ربطه مع جدول في قاعدة البيانات أما ال query builder او مُنشئ الإستعلامات و هي نفس الطريقة التي ذكرتها و نستخدم فيها ال DB facade و هي عبارة عن واجهة تسهل التعامل مع قاعدة البيانات بشكل سلس.

كلا الطريقتين تؤديان نفس الغرض، و إن كانت طريقة مُنشئ الإستعلامات أسرع بنسبة صغيرة و افضل من ناحية الأداء من رابط الكائنات بالعلاقات في بعض الأحيان إلا أن مُعظم مُطوري لارافيل يستخدمون eloquent لكون الشيفرات التي يتم كتابتها به مقروءة بشكل كبير، إن كان المُطور سيعتمد بشكل كلي على query builder و لا يستعمل النماذج (models) نهائياً فإستعماله للإطار و لمفهوم MVC خاطئ خصوصا إن كان المشروع كبير و العلاقات الموجوة بين الجداول كثيرة، فإستعمال الquery builder لا يعني بالضرورة الإستغناء عن النماذج (models). و إستعمال الquery builder لا يعني بالضرورة أيضاً عدم إستخدام eloquent و العكس صحيح.

شخصياً استخدم eloquent و أحياناً عندما يكون الإستعلام مُعقد قليلاً و كمية البيانات التي يتم معالجتها كبير جداً في عمليات البحث و الفلترة او جلب تقارير من بيانات ضخمة في هذه الحالة الأفضل إستخدام Query Builder.

انضم إلى النقاش

يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.

زائر
أجب على هذا السؤال...

×   لقد أضفت محتوى بخط أو تنسيق مختلف.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   جرى استعادة المحتوى السابق..   امسح المحرر

×   You cannot paste images directly. Upload or insert images from URL.

  • إعلانات

  • تابعنا على



×
×
  • أضف...