NestJS / الأساسي: الوحدات وعقود الطلب / الدرس 3
المزودون والرموز وحقن المنشئ
اربط القدرات برموز فعلية ثابتة وافصل البناء عن استعمال المجال.
في هذه الصفحة
أهداف الدرس
- ميز واجهة TypeScript عن رمز حقن موجود وقت التشغيل.
- اشرح كيف يتجاوز البناء اليدوي ربط الحاوية.
سجل قدرة واحقن عقدها
المزود قيمة أو مثيل تديره منظومة الاعتماد. تستطيع الفئة ذات Injectable المشاركة في الحقن لكنها تحتاج التسجيل في وحدة مرئية. يظهر المنشئ الاعتمادات ويسمح ببديل مضبوط في الاختبار. تجنب استيراد مصدر عام مضبوط داخل كل خدمة فيربط المجال بالبدء والاعتماد السري. اختر قدرة ضيقة كقراءة بطاقات مؤهلة بدلاً من مقبض قاعدة غير مقيد. تربط الحاوية الكائنات ولا تحدد معنى الوصول والفشل؛ يجب أن يصرح به عقد الخدمة حتى يفهم المستهلك ما الذي يحق له توقعه من الاعتماد.
استخدم رمزاً فعلياً لواجهة تمحى بعد الترجمة
تمحى واجهات TypeScript وقت التشغيل فلا تستخدم الحاوية اسمها كهوية فعلية. يستعمل الجزء رمز Symbol مصدراً وInject صريحة. يجب أن تستورد جهة التسجيل والاستهلاك الكائن نفسه؛ ينشئ Symbol آخر بالوصف نفسه هوية مختلفة. يفترض التنفيذ ولا يبنيه هنا. يتيح النمط بديلاً اختبارياً دون تغيير منطق الخدمة. ضع الرموز في ملف قليل الاعتمادات لتجنب دورات استيراد تربك التهيئة. الوصف النصي يساعد القراءة لكنه ليس قاعدة المساواة التي تحل بها الحاوية الاعتماد.
export const COURSE_READER = Symbol("COURSE_READER");
@Injectable()
export class CatalogService {
constructor(@Inject(COURSE_READER) private readonly reader: CourseReader) {}
}
// Register in an owning module:
// { provide: COURSE_READER, useClass: StoredCourseReader }CourseReader واجهة ترجمة وCOURSE_READER هوية فعلية مشتركة. الاستيرادات والتنفيذ غير مضمنة فالجزء غير مشغل.
دع الحاوية تملك المثيلات التي يديرها الإطار
لا يطلب new CatalogService يدوياً حل الاعتماد أو تطبيق النطاق أو دورة الحاوية. يفيد ذلك في اختبار نقي باعتمادات مقدمة عمداً ويختلف عن ربط التطبيق. وقد ينشئ تسجيل الخدمة مستقلة في وحدات متعددة مثيلات بدلاً من مشاركة المزود المصدر المقصود. راجع المالك وعلاقة التصدير والاستيراد. لا يجعل المزخرف الفئة مكتشفة عالمياً ولا يجعل استيراد TypeScript المزود مرئياً لوحدة أخرى. افصل مشكلة وجود الرمز في الملف عن مشكلة تسجيله في الحاوية قبل إضافة تسجيلات قد تضاعف الموارد بلا حاجة.
افحص هوية الرمز دون حاوية
توضح الخريطة أن الوصف المتساوي لا يجعل رمزين متبادلين. يحل الاسم المستعار للكائن الأصلي القيمة، ولا يحل الرمز الجديد. هذا سلوك هوية JavaScript لا اختبار حاوية. يعزل سبب عدم التطابق قبل بحث الوحدات والنطاق. لا تحول الرمز لنص وتستعمل وصفه بديلاً إلا باختيار نظام رموز مختلف عمداً. تمنع ملكية الرمز المصدر الثابتة المخالفة والتسمية الملتبسة. لا تثبت الخريطة أن الوحدة صدرت مزودها؛ إنها تختبر فقط شرط الهوية الذي سيحتاجه الربط الحقيقي.
const token=Symbol("COURSE_READER");
const alias=token; const other=Symbol("COURSE_READER");
const bindings=new Map([[token,{name:"synthetic-reader"}]]);
console.assert(bindings.get(alias).name === "synthetic-reader");
console.assert(bindings.get(other) === undefined);يحل الاسم المستعار ولا يحل الرمز الجديد بالوصف نفسه دون تسجيل مزود في Nest أو اختبار حل اعتماده.
حل أخطاء الربط بالرسم لا بمزيد من العام
حدد الرمز وموضع المنشئ والمالك والمستهلك عند فشل البناء. افحص التسجيل والتصدير والاستيراد قبل جعل الوحدة عامة أو تكرار عميل مصدر. قد تفشل دالة مصنع أثناء الإعداد وهذا غير رمز مجهول؛ احفظ الفرق دون أسرار في التشخيص. ترجم وحدة اختبار صغيرة ببدائل عند الإذن. يشغل المقرر خريطة الهوية فقط لا المزخرف أو بيانات الانعكاس أو الحاوية. لا يجعل القيد كل خطأ وقت تشغيل مجرد تهجئة؛ فمسار المصنع ونطاق المزود وتهيئة الاعتماد أسباب تحتاج أدلتها الخاصة.
الأخطاء الشائعة وإصلاحها
لا تحل واجهة وقت التشغيل
- لماذا يحدث؟
- استعمل نوع يمحى بعد الترجمة بوصفه هوية حقن وقت التشغيل.
- كيف تصلحه؟
- اربط القدرة برمز فعلي مشترك واستعمل الرمز نفسه عند الحقن.
- كيف تتجنب تكراره؟
- صدر الرموز من وحدة مستقرة قليلة الاعتمادات.
لا يتطابق وصفا رمز متساويان
- لماذا يحدث؟
- أنشئ كائنان مختلفان من Symbol رغم تساوي الوصف النصي لهما.
- كيف تصلحه؟
- استورد كائن الرمز الأصلي المصدر بدلاً من إنشاء رمز جديد.
- كيف تتجنب تكراره؟
- اختبر تطابق هوية الرمز وراجع تعريفاته المكررة.
يفقد new اليدوي اعتمادات الحاوية
- لماذا يحدث؟
- تجاوز البناء اليدوي حل الاعتمادات وإدارة النطاق اللذين توفرهما الحاوية.
- كيف تصلحه؟
- استخدم تسجيل الحاوية في التطبيق، أو قدم بدائل صريحة في اختبار الوحدة.
- كيف تتجنب تكراره؟
- اجعل الطرف المسؤول عن بناء كل مثيل ظاهراً في التصميم.
اختبر فهمك
1. هل يكفي استيراد فئة خدمة إلى ملف لجعل مزودها مرئياً في Nest؟
اعرض الحل المشروح
لا. يتيح استيراد اللغة قيمة الفئة داخل الملف، أما رؤية المزود في Nest فتتبع تسجيل الوحدات وتصديراتها واستيراداتها. حدد الوحدة المالكة واستهلك القدرة التي تصدرها، بدلاً من إضافة مزودين مكررين لإسكات خطأ حل الاعتماد. تحقق من الربط الفعلي باختبار حاوية محدد عندما يكون تشغيل ذلك الاختبار مأذوناً به.
2. لماذا يمكن أن يناسب البناء اليدوي اختبار وحدة نقياً؟
اعرض الحل المشروح
يستطيع الاختبار تقديم كل اعتماد مباشرة ثم فحص سلوك المجال من دون بدء الإطار. هذا تحكم مقصود في بناء الكائن، وليس دليلاً على صحة ربط حاوية Nest. احتفظ باختبار دمج صغير منفصل للرموز ورؤية الوحدات ونطاقات المزودين، حتى يطابق ادعاء كل اختبار الحد الذي شارك فعلياً في تنفيذه.
أهم ما تعلمته
- تحدد الرموز الفعلية ورؤية الوحدة الحقن معاً.
- يقدم البناء اليدوي وبناء الحاوية دليلين مختلفين.