إزاي Unit of Work وRepository Pattern ينقذوا الكود

مرة حصلي موقف كارثي … كنت شغال على مشروع e-commerce، واليوزر عمل Order جديد . قلت أضيفه بسرعة… وفجأة
هنا هتفهم ليه الـ Unit of Work والـ Repository Pattern بيخلو الكود أنضف وأذكى .

ليه ده مهم؟
لأنهم هيوفّروا عليك لخبطة كبيرة في التعامل مع الداتابيز، وهيخلو أي تعديل مستقبلي أسهل مليون مرة .

تخيل معايا

• لازم تضيف الـ Order في جدول Orders.
• تقلل الكمية من جدول Products .
• تسجّل عملية الدفع في Payments .

لو خطوة واحدة بس وقعت (زي إن الـ Order اتسجل لكن الكمية منقصتش)، الداتا كلها تبوز .

وهنا بييجي دور البطل : Unit of Work
الفكرة

• بتجمع كل العمليات كأنها Transaction واحدة .
• يا كلها تحصل صح … يا كلها تتلغي Rollback وكأنها ما حصلتش .
• الداتابيز بتفضل سليمة ومفيش حاجة اسمها "نص عملية".

طيب إزاي بيعرف إيه اللي هيتضاف أو يتعدل؟
هنا بيظهر صاحبه الانتيم : Repository Pattern.

الـ Repository هو الوسيط :

• بدل ما تكتب Queries في كل حتة، بتكلم كائن نضيف زي UserRepository أو ProductRepository.
• الـ Business Logic ما يعرفش قواعد البيانات جواها إيه . سواء SQL Server أو MongoDB أو حتى Text File، كله واحد.

الميزة الكبيرة: الكود بتاعك يبقى Decoupled.
بكرة تحب تغير ORM أو نوع الداتابيز → تغيّر الـ Repositories بس. الـ Business Logic ما يتلمسش .

إزاي الاتنين بيشتغلوا مع بعض؟

1. الكود بتاعك بيكلم الـ UnitOfWork.
2. تطلب منه الـ Repository اللي محتاجه.
3. تستخدم الـ Repository عشان تضيف أو تعدل.
4. في الآخر تقول كلمة واحدة: Complete() .

كده كل العمليات هتتنفذ مع بعض جوه Transaction واحدة.

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