
- بواسطة x32x01 ||
مرة حصلي موقف كارثي
… كنت شغال على مشروع e-commerce، واليوزر عمل Order جديد. قلت أضيفه بسرعة… وفجأة حصل مشاكل في الداتا!
هنا هتفهم ليه الـ Unit of Work والـ Repository Pattern بيخلو الكود أنضف وأذكى
.
ليه ده مهم؟
لأنهم هيوفّروا عليك لخبطة كبيرة في التعامل مع الداتابيز، وهيخلو أي تعديل مستقبلي أسهل مليون مرة.
تخيل معايا السيناريو:
لو خطوة واحدة بس وقعت (زي إن الـ Order اتسجل لكن الكمية منقصتش)، الداتا كلها هتبوز
وهنا بييجي دور البطل: Unit of Work.
Unit of Work: البطل اللي بيحمي الداتا
الفكرة:
Repository Pattern: الوسيط الذكي
الـ Repository هو الوسيط بين الـ Business Logic والداتابيز:
الميزة الكبيرة: الكود بتاعك يبقى Decoupled.
لو بكرة عايز تغير ORM أو نوع الداتابيز → تغيّر الـ Repositories بس. الـ Business Logic ما يتلمسش
إزاي الاتنين بيشتغلوا مع بعض؟
كده كل العمليات هتتنفذ مع بعض جوه Transaction واحدة، والداتابيز تبقى سليمة دايمًا
طب ما الـ DbContext في EF Core بيعمل كده أصلاً؟
صح … بس لو استخدمته مباشر، هتربط نفسك بالـ Entity Framework للأبد.
لو حبيت تعمل Unit Test من غير داتابيز؟ صعب جدًا
الـ Abstraction اللي بنعمله هنا بيفصل بين إيه يحصل (Business Logic) وبين إزاي يحصل (Implementation).
نصيحة للمطورين
استخدم Unit of Work + Repository Pattern في أي مشروع كبير أو مشروع e-commerce، هتلاقي الكود أنضف، أخطاء أقل، وتقدر تعمل Testing بسهولة.

هنا هتفهم ليه الـ Unit of Work والـ Repository Pattern بيخلو الكود أنضف وأذكى

ليه ده مهم؟
لأنهم هيوفّروا عليك لخبطة كبيرة في التعامل مع الداتابيز، وهيخلو أي تعديل مستقبلي أسهل مليون مرة.تخيل معايا السيناريو:
- لازم تضيف الـ Order في جدول Orders.
- تقلل الكمية من جدول Products.
- تسجّل عملية الدفع في Payments.
لو خطوة واحدة بس وقعت (زي إن الـ Order اتسجل لكن الكمية منقصتش)، الداتا كلها هتبوز

وهنا بييجي دور البطل: Unit of Work.
Unit of Work: البطل اللي بيحمي الداتا
الفكرة:- بيجمع كل العمليات كأنها Transaction واحدة.
- يا كلها تحصل صح … يا كلها تتلغي (Rollback) وكأنها ما حصلتش.
- الداتابيز بتفضل سليمة ومفيش حاجة اسمها "نص عملية".
C#:
using (var unitOfWork = new UnitOfWork())
{
unitOfWork.Orders.Add(newOrder);
unitOfWork.Products.Update(product);
unitOfWork.Payments.Add(payment);
unitOfWork.Complete(); // هنا كل العمليات بتتنفذ مع بعض
}
Repository Pattern: الوسيط الذكي
الـ Repository هو الوسيط بين الـ Business Logic والداتابيز:- بدل ما تكتب Queries في كل حتة، بتكلم كائن نضيف زي UserRepository أو ProductRepository.
- الـ Business Logic ما يعرفش قواعد البيانات جواها إيه: سواء SQL Server أو MongoDB أو حتى Text File، كله واحد.
الميزة الكبيرة: الكود بتاعك يبقى Decoupled.
لو بكرة عايز تغير ORM أو نوع الداتابيز → تغيّر الـ Repositories بس. الـ Business Logic ما يتلمسش

إزاي الاتنين بيشتغلوا مع بعض؟
- الكود بتاعك بيكلم الـ UnitOfWork.
- تطلب منه الـ Repository اللي محتاجه.
- تستخدم الـ Repository عشان تضيف أو تعدل.
- في الآخر تقول كلمة واحدة: Complete().
كده كل العمليات هتتنفذ مع بعض جوه Transaction واحدة، والداتابيز تبقى سليمة دايمًا

طب ما الـ DbContext في EF Core بيعمل كده أصلاً؟
صح … بس لو استخدمته مباشر، هتربط نفسك بالـ Entity Framework للأبد.لو حبيت تعمل Unit Test من غير داتابيز؟ صعب جدًا

الـ Abstraction اللي بنعمله هنا بيفصل بين إيه يحصل (Business Logic) وبين إزاي يحصل (Implementation).
نصيحة للمطورين
استخدم Unit of Work + Repository Pattern في أي مشروع كبير أو مشروع e-commerce، هتلاقي الكود أنضف، أخطاء أقل، وتقدر تعمل Testing بسهولة. التعديل الأخير: