محتويات الدورة

ASP.NET Core / الأساسي: HTTP وتركيب التطبيق / الدرس 2

ترتيب الوسطاء وحدود الأخطاء

اشرح سير الطلب للأمام والاستجابة للخلف والاختصار واعتماد الاستجابة قبل تركيب السلوك المشترك.

وقت القراءة التقريبي: 4 دقيقةتاريخ مراجعة المحتوى
في هذه الصفحة

أهداف الدرس

  • تتبع السلوك قبل استدعاء next وبعده.
  • تحديد موضع معالجة الأخطاء والمنطق المعتمد على نقطة النهاية عن قصد.
  • تمييز اختصار خط الطلب من إكمال عملية الأعمال كلها.

يغلف الوسيط مفوض الطلب التالي

يمكن للوسيط أن يعمل قبل next ثم ينتظر المفوض التالي ويعمل بعده. يسير الطلب بترتيب التسجيل، وينفذ العمل اللاحق بالعكس عند اكتمال النداءات بصورة عادية. يختصر مكون لا يستدعي next بقية الخط. لذلك يغير الترتيب السلوك لا أسلوب كتابة المصدر فقط.

يبني البرنامج الأول سلسلة ApplicationBuilder في الذاكرة ويسجل ترتيب التنفيذ. يستخدم المنشئ الفعلي دون مضيف أو مستمع. يوضح الأثر تركيب المفوضات، وتبقى معالجة الاتصال واعتماد الاستجابة الحقيقي خارج الاختبار.

csharp تتبع تركيب وسطاء فعلي في الذاكرة
using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.DependencyInjection;

using var services = new ServiceCollection().BuildServiceProvider();
var builder = new ApplicationBuilder(services);
var trace = new List<string>();
builder.Use(next => async context => { trace.Add("outer-before"); await next(context); trace.Add("outer-after"); });
builder.Use(next => async context => { trace.Add("inner-before"); await next(context); trace.Add("inner-after"); });
builder.Run(context => { trace.Add("terminal"); return Task.CompletedTask; });
await builder.Build()(new DefaultHttpContext());
Console.WriteLine(string.Join(">", trace));
الناتج المتوقع
outer-before>inner-before>terminal>inner-after>outer-after

ينفذ المفوض الطرفي بين مراحل العمل السابق ومراحل العمل اللاحق المعكوسة؛ ولا يفتح مستمع HTTP.

للمكونات شروط سابقة ونطاق ملاحظة

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

قد تضيف WebApplication بعض الوسطاء آليا عند اكتشاف خدمات. وقد يلزم ترتيب صريح عندما لا تناسب الافتراضيات CORS أو المصادقة أوالسلوك الطرفي. افصل التسجيل من التنفيذ وتحقق من نموذج التطبيق للإصدار المحدد.

يمنع الفرع الطرفي ما بعده من العمل

يستخدم البرنامج الثاني علما اصطناعيا للصيانة ليوقف التنفيذ قبل مفوض التطبيق، فيعيد 503 ويتأكد من عدم تشغيله. هذا اختبار صيانة لا آلية مصادقة. يحدد موضعه في الخط الفعلي هل تحيط به السجلات والرؤوس الأمنية ومعالجة الخطأ.

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

csharp التحقق من اختصار الصيانة
using System;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Http;

bool maintenance = true;
bool applicationRan = false;
RequestDelegate application = context => { applicationRan = true; return Task.CompletedTask; };
RequestDelegate gate = async context =>
{
    if (maintenance) { context.Response.StatusCode = StatusCodes.Status503ServiceUnavailable; return; }
    await application(context);
};
var context = new DefaultHttpContext();
await gate(context);
Console.WriteLine($"status={context.Response.StatusCode} applicationRan={applicationRan}");
الناتج المتوقع
status=503 applicationRan=False

يعيد العلم المحلي حالة 503 قبل تنفيذ مفوض التطبيق.

لا تستبدل الاستجابة المعتمدة بأثر رجعي

بعد بدء الرؤوس أوالجسم في الخادم الفعلي لا يستطيع اللاحق استبدال الحالة والرؤوس بحرية كأن شيئا لم يرسل. راع HasStarted في ترجمة الخطأ واستخدم OnStarting لما يناسب ما قبل الاعتماد. تجنب إضافة جسم بعد next إذا ربما انتهت النقطة أو بثت أو فشلت جزئيا.

يفيد DefaultHttpContext بمخزن ذاكرة ولا يحاكي كل انتقال اعتماد للخادم. لا يثبت نجاح تعديل رأس بعد MemoryStream صلاحية العملية على Kestrel. استخدم تكاملا معزولا مناسبا لهذا الادعاء، وأبق تأكيدات المكون ضمن حدها.

يحفظ حد الخطأ الدليل المفيد

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

اختبر الترتيب والفرع الطرفي وفشل اللاحق وفشل عمل ما بعده والاستجابة التي بدأت. افحص من نفذ وأي عقد ظل ممكنا. قد يتجنب الخط استثناء غير ملتقط مع حالة متناقضة أوخرج مكرر أوتدقيق مفقود.

الأخطاء الشائعة وإصلاحها

يتوقع أن ينفذ العمل اللاحق بالترتيب الأمامي نفسه.

لماذا يحدث؟
لم يفهم نموذج تغليف الاستدعاءات وفكها عند العودة.
كيف تصلحه؟
تتبع استدعاءات next المنتظرة وترتيب الاكتمال المعكوس.
كيف تتجنب تكراره؟
احتفظ باختبار تراجعي صغير لترتيب التنفيذ.

تنفذ نقطة نهاية محمية قبل تطبيق التفويض.

لماذا يحدث؟
وضع السلوك الأمني بعد الفعل الذي يفترض أن يحرسه.
كيف تصلحه؟
ضع مكونات التفويض المدعومة قبل تنفيذ نقطة النهاية.
كيف تتجنب تكراره؟
اختبر الطلبات الممنوعة إلى جانب الطلبات المسموحة.

تحاول معالجة الخطأ استبدال استجابة بدأ إرسالها.

لماذا يحدث؟
أهملت الافتراضات المحلية اعتماد الخادم للاستجابة.
كيف تصلحه؟
صمم ترجمة الخطأ وفق حالة الاستجابة وسلوك البث.
كيف تتجنب تكراره؟
ضمّن حالة تكامل فعلية عند اختبار اعتماد الاستجابة.

اختبر فهمك

1. اختصر طلب قبل الوصول إلى مكون تسجيل. لماذا قد يختفي الطلب من سجلات ذلك المكون؟

اعرض الحل المشروح

الوسيط لاحق فلا ينفذ عندما لا تصله next. انقل الملاحظة الخارجية المطلوبة إلى موضع أبكر أو صمم التسجيل حول الحد المقصود كله، مع ضبط البيانات الحساسة. اختبر العادي والمختصر. لا تفترض تنفيذ كل مسجل لكل طلب؛ تحدد next والفروع إمكان بلوغه.

2. لماذا لا يكفي اختبار بمجرى ذاكرة لإقرار تغيير الحالة بعد إخراج الجسم؟

اعرض الحل المشروح

قد لا تنفذ ميزة الذاكرة انتقالات النقل واعتماد الرؤوس نفسها لدى الخادم. تثبت الكتابة محليا لا ما أرسل فعلا للعميل. اختر الحالة والرؤوس قبل الاعتماد، واختبر السلوك الخاص بالخادم في تكامل معزول مدعوم. لا تجعل الأداة البديلة تعيد تعريف HTTP.

أهم ما تعلمته

  • يضبط ترتيب الوسطاء إمكان الوصول إلى المكونات وما تستطيع ملاحظته.
  • تغلف استدعاءات next المنتظرة العمل اللاحق، ثم تفك الاستدعاءات بترتيب معكوس.
  • اعتماد الخادم للاستجابة حد قد لا يحاكيه البديل المحلي.

المراجع الرسمية