زي انهارده من سنه اول بدايت رحلتي مع الدوت نت وكنت فاكر ان المجال مش بتاعي وان ده مش مكاني
لاكن مع الصبر والاستمرار ولو مجهود ضعيف بفضل ربنا وكرمه سنه كامله بدون انقطاع والحمد لله قدرت ان ابني مشاريع حقيقيه
والفضل ل صديقي بعد كرم ربنا شجعني علي ده . دعوه حلوه له بظهر الغيب 🤍
4
https://t.co/RdW5dXdqfq.AddDbContextFactory(options =>
options.UseSqlServer(connectionString));
Performance Comparison
Sequential → 300ms
Parallel → 100ms
تحسين كبير في سرعة الاستجابة
Golden Rule
استخدم Parallel لو الاستعلامات مستقلة
متستخدموش لو في dependency بين الاستعلامات
Optimizing Database Calls in https://t.co/mGiyhSqQ8N Core
لما تبني API وبتتعامل مع الداتابيز فيه فرق كبير بين طريقتين في تنفيذ الاستعلامات
Sequential Execution
var parent = await parentRepo.GetAsync
var children = await childRepo.GetAsync
كل استعلام بيستنى اللي قبله →وقت أطول
3
Important Note
لو بتستخدم Entity Framework Core
DbContext مش Thread-Safe
يعني مينفعش تستخدم نفس الـ context في أكتر من Task
الحل
استخدم IDbContextFactory علشان كل Task يشتغل بـ DbContext منفصل
2
Parallel Execution
var parentTask = parentRepo.GetAsync();
var childrenTask = childRepo.GetAsync();
await Task.WhenAll(parentTask, childrenTask);
الاستعلامات بتتنفذ في نفس الوقت → اداء اسرع
3
Important Note
لو بتستخدم Entity Framework Core
DbContext مش Thread-Safe
يعني مينفعش تستخدم نفس الـ context في أكتر من Task
الحل
استخدم IDbContextFactory علشان كل Task يشتغل بـ DbContext منفصل
الفتره الاخيره ذاكرت (Minimal Api In https://t.co/QlmvfTv3ik)
1: بدات بفهم دعم Http Verbs داخل Minimal APIوإزاي كل
Verb (Get, Post, Put,Delete)
مش مجرد نوع Request
لكنه عقد واضح بيحدد سلوك الـ Endpoint وطبيعته
وبيخلي الـ API معتمد علي ��فسه من غير الاعتماد على Controllers
من النقط المهمه الي ركزت عليها وهي Grouped Endpoints
وده عن طريق ان استخدم prefix موحد وبضم تحته مجموعه من ال EndPoints
يعني مثلا لو عاوز احط validaton علي مجموعه Endpoint ف هروح اضمهم تحت mapGroup واحد
بعد كده درست Endpoint Anatomy
1: ان اعرف ال Route بشكل مباشر
2:Model Binding تلقائي من ال Route او ال Body
3: Delegete بيمثل نقطه الدخول لل Requestمن الاخر ال logic الي هيحصل
3: Response خصوصا (IResult , Result)
ده بقا الي بيحدد هل العمليه تمت ولا لا عن طريق ال StatussCode
زي انهارده من سنه اول بدايت رحلتي مع الدوت نت وكنت فاكر ان المجال مش بتاعي وان ده مش مكاني
لاكن مع الصبر والاستمرار ولو مجهود ضعيف بفضل ربنا وكرمه سنه كامله بدون انقطاع والحمد لله قدرت ان ابني مشاريع حقيقيه
والفضل ل صديقي بعد كرم ربنا شجعني علي ده . دعوه حلوه له بظهر الغيب 🤍
هعمل 2 Route :واحد ل routeالقديم وواحد للroute الجديد
عاوزين نشوف مسار ال request لحد م يرجعلي response
1 : Request سوا اي طريقه من الاربعه
2 : IApiVersionReader بيقرا ال version الي مبعوته في ال request بحيث يشوف هيشتغل علي اي version
ثم يشوف ال controller الي نفس ال version
Api Versioning
تخيل ان عندك Api شغال في ال Production وفجاه محتاج تضيف Feature جديده
مثلا عندنا Response معين عدلناه
ان بدل ال م يرجع
{ "name": "Hesham"}
لا عاوزه يرجعلي
{ "name": " Hesham ", "phone":"010xxxxxx"}
طيب لو انا مش معرف ال client ان عندك تعديل معين ف دي مشكله👇🏾
ثانيا نسجل ال
Services
https://t.co/RdW5dXdqfq.AddApiVersioning(options=>{
options.DefaultApiVersion = new ApiVersion(0,1)
options.AssumeDefaultVersionWhenUnspecified = true;
options.ReportApiVersions = true;
وهنا هسجل ال service الخاصه ب الطريقه الي عاوز اشتغل بيها
});
نتكلم بقا عن الهدف الاساسي
Api Version يعني انك تعمل اكتر من version لل api بحيث يكون عندنا نقطتين
1 : ال القديمه شغاله زي م هي
2 : ال الجديه شغاله ب ال feature الجديده
وبكدا اكون مجبرتش ال user القديم انه يستخدم ال الجديده بتاعتي وفي نفس الوقت يقدر يحدث الجديده وقت م يحب