المشاركات

Entity Framework - لماذا نحتاج لضبط الكيانات؟

8.1 Entity Framework - لماذا نحتاج لضبط الكيانات؟ في Entity Framework Core، عندما نقوم بإنشاء الكيانات (Entities)، فهي تمثل الجداول (Tables) في قاعدة البيانات. ولكن بمجرد تعريف الكيانات باستخدام الخصائص (Properties)، لا يكون كل شيء مكتملًا أو مضبوطًا بشكل دقيق. هنا تأتي أهمية ضبط الكيانات (Entity Configuration) لضمان أن قاعدة البيانات تعكس النماذج (Models) كما نريد بالضبط. 🔹 ما معنى ضبط الكيانات؟ ضبط الكيان يعني تحديد تفاصيل إضافية حول كيفية تخزين الكيان في قاعدة البيانات. هذا يشمل تحديد: نوع البيانات لكل خاصية (Property). تعيين المفاتيح الأساسية (Primary Keys). تعريف القيود (Constraints) مثل الطول الأقصى للسلاسل النصية (MaxLength). تحديد العلاقات بين الكيانات (Relationships) مثل One-to-Many أو Many-to-Many. وضع خصائص مطلوبة (Required) أو افتراضية (Default Values). 🔹 لماذا نحتاج لضبط الكيانات بدقة؟ لضمان سلامة البيانات: ضبط القيم المطلوبة، وأنواع البيانات، يمنع إدخال بيانات خاطئة أو غير مكتملة. لتحسين الأداء: عندما نحدد الأطوال الدقيقة...

Entity Framework - مقدمة عن Entity Framework

مقدمة عن Entity Framework 📜 لمحة تاريخية عن Entity Framework - أول إصدار من Entity Framework ظهر سنة 2008 كجزء من .NET Framework. - كان اسمه الرسمي ببساطة "Entity Framework"، ويعمل على ربط التطبيقات مع قواعد بيانات SQL بطريقة برمجية. - Entity Framework وفر وقتها أسلوبين رئيسيين للعمل: Database First ➔ إنشاء الكود انطلاقًا من قاعدة بيانات موجودة. Model First ➔ إنشاء قاعدة البيانات انطلاقًا من نموذج (Model) مرسوم. ✅ مع الوقت تطورت EF وتم إضافة أسلوب جديد يسمى Code First الذي أصبح من أكثر الطرق استخدامًا اليوم. 🔗 إصدارات Entity Framework قبل EF Core Entity Framework 1.0 (2008) - الإصدار الأول وكان محدود الإمكانيات. Entity Framework 4.0 (2010) - تحسينات كبيرة ودعم أفضل لـ POCO classes. Entity Framework 5.0 و6.0 (2012-2013) - دعم مميزات متقدمة مثل Migrations وتحسين الأداء. 💡 ملاحظة: لم يكن هناك EF 2.0 أو EF 3.0 رسميًا. 🚀 لماذا تم تطوير Entity Framework Core؟ مع ظهور .NET Core، احتاجت مايكروسوفت إلى نسخة خفيفة وعصرية م...

Entity Framework - التعامل مع Migrations الحساسة (مثل حذف أعمدة أو تغيير أسماء أعمدة).

Entity Framework Core - التعامل مع Migrations الحساسة (مثل حذف أعمدة أو تغيير أسماء أعمدة) 🧠 ما المقصود بالـ Migrations الحساسة؟ Migrations الحساسة تعني التغييرات التي قد تسبب فقدان بيانات أو تعطل النظام إذا لم تتم بعناية، مثل: حذف أعمدة (DROP COLUMN). تغيير أسماء أعمدة (RENAME COLUMN). حذف جداول كاملة. تغيير أنواع بيانات الحقول بطريقة غير متوافقة. ✅ هذه العمليات يجب التعامل معها بحذر شديد لتفادي فقدان البيانات أو فسادها. 🔗 أهم النصائح للتعامل مع Migrations الحساسة 1. لا تحذف الأعمدة مباشرة - بدلاً من حذف العمود فجأة، ابدأ بوضعه كـ Deprecated لفترة. - أخبر فريق العمل أن هذا العمود سيتم حذفه لاحقًا. 2. خذ نسخة احتياطية دائمًا - قبل أي عملية حذف أو تعديل على قاعدة الإنتاج، يجب أخذ Backup كامل. 3. استخدم سكربتات SQL مخصصة بدل الاعتماد الكامل على EF Core - عند حذف أعمدة أو إعادة تسميتها، من الأفضل كتابة سكربت SQL مخصص يدويًا بدلاً من الاعتماد فقط على السكربتات التلقائية. 4. لا تغير اسم العمود مباشرة ➔ استخدم خطوات انتقالية لو أ...

Entity Framework - متى تستخدم Migrations تلقائيًا؟ ومتى تكتب SQL Scripts يدوياً؟

Entity Framework Core - متى تستخدم Migrations تلقائيًا؟ ومتى تكتب SQL Scripts يدويًا؟ 🧠 مقدمة في العمل مع Entity Framework Core، أمامك خياران لتحديث قاعدة البيانات: استخدام Migrations التلقائية عبر أوامر مثل Update-Database . أو توليد سكربتات SQL يدويًا وتنفيذها بنفسك. كل خيار له وقت مناسب لاستخدامه بناءً على طبيعة المشروع والبيئة التي تعمل عليها. 🛠️ متى تستخدم Migrations التلقائية؟ تستخدم Migrations التلقائية (Update-Database) عندما: تعمل في بيئة تطوير (Development Environment). تجري تعديلات متكررة على الكود والبيانات بشكل يومي. المشروع صغير أو متوسط الحجم ولا يحتوي على بيانات إنتاج حساسة. أنت تتحكم بشكل كامل في قاعدة البيانات ولا يوجد قيود من فريق DBA. ✅ في بيئة التطوير، السرعة والمرونة أهم من الحذر، لذلك Migrations التلقائية مريحة جدًا. 🛠️ متى تكتب SQL Scripts يدويًا؟ تستخدم SQL Scripts اليدوية عندما: تعمل في بيئة إنتاج (Production Environment) أو اختبار رسمي (Staging). البيانات الموجودة حيوية وحساسة ولا تحتمل فقدان ...

Entity Framework - كيفية عمل Migrations يدوية عند وجود فريق عمل كبير.

Entity Framework Core - كيفية عمل Migrations يدوية عند وجود فريق عمل كبير 🧠 لماذا نحتاج لعمل Migrations يدوية مع فريق كبير؟ عندما يعمل أكثر من مطور على نفس قاعدة البيانات في مشروع واحد، قد تحدث مشاكل مثل: تضارب بين Migrations. فقدان تزامن بين القاعدة والكود. تنفيذ تغييرات عشوائية تسبب أعطال في الإنتاج. ✅ الحل هو: إدارة Migrations بطريقة منظمة (يدويًا أو شبه أوتوماتيكية) مع الاتفاق على إجراءات عمل واضحة بين الفريق. 🔗 الخطوات المثالية لإدارة Migrations يدويًا مع الفرق 1. تحديد مسؤول Migrations - حدد شخصًا أو فريقًا مسؤولًا عن إنشاء ومراجعة Migrations فقط. - باقي الفريق يضيف التعديلات على الـ Models، لكن لا ينفذ Migrations بدون مراجعة. 2. إنشاء Migration مركزية واحدة لكل مجموعة تغييرات - اجمع التعديلات التي تمت على الـ Models. - أنشئ Migration واحدة شاملة لكل التعديلات في مرحلة معينة. - سمّها باسم معبر (مثلاً: AddUserManagementFeatures ). 3. توليد سكربت SQL ومراجعته قبل التنفيذ - بعد إنشاء Migration، استخدم: Script-Migration - راجع...

Entity Framework - العمل مع Migration History Table.

Entity Framework Core - العمل مع Migration History Table 🧠 ما هو Migration History Table؟ جدول __EFMigrationsHistory هو جدول خاص تقوم Entity Framework Core بإنشائه داخل قاعدة البيانات بشكل تلقائي. مهمة هذا الجدول: تسجيل كل Migration تم تنفيذها بالفعل على قاعدة البيانات. مساعدة EF Core في معرفة أي Migrations تم تنفيذها وأيها لم يتم بعد. تسهيل التراجع أو التقدم في Migrations حسب الحاجة. 📄 شكل جدول __EFMigrationsHistory الجدول يحتوي عادة على عمودين رئيسيين: MigrationId : اسم الـ Migration المنفذة. ProductVersion : نسخة EF Core التي استخدمت أثناء إنشاء هذه Migration. مثال على محتويات هذا الجدول: +--------------------------------------+-------------------+ | MigrationId | ProductVersion | +--------------------------------------+-------------------+ | 20240427093000_InitialCreate | 8.0.4 | | 20240427101500_AddProductsTable | 8.0.4 | | 20240427113000_AddCategoriesTable | 8...

Entity Framework - كيف تدير إصدارات قاعدة البيانات بين بيئات التطوير والإنتاج.

Entity Framework Core - كيف تدير إصدارات قاعدة البيانات بين بيئات التطوير والإنتاج 🧠 لماذا نحتاج لإدارة إصدارات قاعدة البيانات؟ في المشاريع الحقيقية عادةً يكون لديك أكثر من بيئة: بيئة التطوير (Development Environment) بيئة الاختبار (Staging Environment) بيئة الإنتاج (Production Environment) لكل بيئة قاعدة بياناتها الخاصة. ✅ لذلك تحتاج إلى طريقة منظمة لضمان أن جميع قواعد البيانات محدثة بنفس التغييرات وبنفس الترتيب. 🔗 كيف يتم إدارة الإصدارات بشكل صحيح؟ إنشاء Migrations محكمة: كل تغيير في الـ Models يجب أن يقابله Migration جديدة باسم واضح ومعبر. تخزين Migrations مع الكود البرمجي: يجب حفظ ملفات Migrations ضمن النظام الخاص بإدارة الإصدارات مثل Git. تطبيق Migrations بنفس الترتيب: كل بيئة تطبق Migrations بالتسلسل الصحيح لضمان تطابق الهياكل. مراجعة السكربتات قبل تطبيقها على الإنتاج: لتفادي أخطاء كارثية مثل حذف أعمدة أو بيانات مهمة. 🛠️ خطوات إدارة Migrations بين البيئات 1. أثناء التطوير - أنشئ Migration مع كل تعديل مهم. - تأكد أن M...