أفضل الممارسات: بناء الخدمات الزاوية باستخدام نمط تصميم الواجهة للأنظمة المعقدة

الخدمات الزاوية

مفهوم الخدمات الزاوي يخلط دائمًا بين newbies وبين خدمات REST من جانب الخادم. إذا كنت لا تزال غير متأكد من ماهية الأمر ، فسأوصيك بقراءة الوثائق الزاوية

تتحمل الخدمات الزاوية مسؤولية توفير بيانات التطبيق / منطق العمل للمكونات. يجب أن تأخذ المكونات / تقدم البيانات إلى الخدمة وتعمل كغراء بين العرض والخدمة. هي الخدمة التي يمكنها أن تقرر ما إذا كنت تريد توفير بيانات وهمية أو الانتقال إلى الخادم وجلب البيانات من قاعدة بيانات / ملف / خدمة (خدمات) أخرى ، إلخ.

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

في النهج الثاني (يتم اتباعه على نطاق واسع) ، يتم إنشاء ميزة خدمة مصغرة محددة. على سبيل المثال ، إذا كان النظام الخاص بك يحتوي على مكونات تسجيل الدخول وتسجيل الدخول ولوحة التحكم ، فيجب عليك إنشاء تسجيل الدخول إلى الخدمة و SignUpService و DashboardService وما إلى ذلك. يجب أن تحتوي كل خدمة على الوظيفة المطلوبة لمكون محدد مستهدف. الآن يبدو هذا التصميم جيدًا ، أليس كذلك؟

مشكلة؟

أثناء إنشاء تطبيق صفحة واحدة كبير ومعقد باستخدام Angular ، ستنتهي قريبًا بمئات وآلاف فئات المكونات. وقد قلت ذلك ، يجب أن يكون لديك عدد مماثل من الخدمات الزاوية حقن. ماهي المشكلة هنا؟

بغض النظر عن طريقة التسمية الجيدة التي اتبعتها لبناء مكونات وخدمات ، يجب أن يكون هناك وقت مطلوب لمعرفة اسم خدمة محدد لفئة معينة. أيضًا قد ينتهي بك الأمر إلى كتابة فئة خدمة مكررة باسم مختلف قليلاً للمكون نفسه عن الفريق الآخر الذي تم إنشاؤه. إذا كنت تعمل في نموذج Extreme Programming ، فمن المفترض أن يواصل مطورو الواجهة الأمامية التبديل بين الوحدات / المكونات / الميزات. يجب ألا يستغرق الأمر وقتًا طويلاً لمعرفة المكونات والخدمات المرتبطة بها.

المحلول

يمكننا حل هذه المشكلة باستخدام نمط تصميم الواجهة.

نمط تصميم الواجهة

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

يجب أن يكون كائن الواجهة محاميًا أو ميسرًا بسيطًا إلى حد ما. لا ينبغي أن يصبح كائن أوراكل أو "إله" معروف.

هذه هي القراءة الجيدة لنمط تصميم الواجهة بالتفاصيل

نمط تصميم الواجهة

واجهة في العمل مع الخدمات الزاوي

أوصي الخطوات التالية لإنشاء خدمات الزاوي باستخدام نمط الواجهة:

حدد جميع خدماتك الزاوية حسب متطلبات عملك و / أو استمر في إضافة المزيد حسب الحاجة.

قم بإنشاء خدمة تسمى "FacadeService" (لا تتردد في استخدام أي اسم آخر هنا)

إنشاء NgModule مشترك وتوفير جميع الخدمات الزاوي

تنفيذ خدمة الواجهة

يجب أن تكون مناقشتنا الرئيسية حول خدمة "FacadeService" فقط.

لقد ناقشنا نهجين الخدمة العملاقة مقابل الخدمة الصغيرة. لقد رأينا إيجابياتهم وسلبياتهم. أفضل حل هو دمج كل منهما لإنشاء واجهة خدمة. الآن ، يجب أن تكون فئة FacadeService من فئة الله ، لكن لن يكون لها وظيفة فعلية بل غلاف على الخدمات الفعلية.

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

الطريقة الأكثر ذكاءً تتمثل في تجميع جميع الخدمات الزاوية داخل خدمة FacadeService وحل مثيلاتها من الوصول الزاوي إلى داخل "الملكية".

دعونا نناقش استخدام AccountService.

لدينا خاصية محددة تسمى accountService داخل FacadeService. يعمل getOrderList () و getAddress () دالات FacadeService كمغلفات للأساليب الفعلية لحساب الخدمة.

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

للوصول إلى محرك Angular DI ، نحتاج إلى حقن خدمة Inejctor Angular المدمجة داخل مُنشئ FacadeService. يجب على injector.get () الاستعلام عن محرك DI الخاص بـ Angular لحل مثيل الخدمة المطلوب إذا تم توفيره. (تذكر SharedModule حيث قدمنا ​​جميع الخدمات؟)

إذا كنت قد لاحظت بعناية ، فقد قمنا بتطبيق نمط تصميم Singleton وكذلك داخل الحصول على قسم الممتلكات من خاصية accountService.

واجهة الاستهلاكالخدمة داخل المكون (المكونات)

لدينا AccountService مجمعة داخل FacadeService وهو جاهز للاستهلاك داخل OrderComponent و AddressComponent.

الانتهاء من النظام المتبقي

على نفس المذكرة من تطبيق accountService ، يمكنك الانتهاء من تنفيذ الخدمات الزاوية الأخرى داخل FacadeService.

تطبيق نمط تصميم الواجهة في الخدمات الزاوية

عرض حي:

مستودع جيثب:

ملخص

يساعدنا نمط تصميم الواجهة في بناء تطبيق Angular معقد من خلال توفير وصول مبسط للعديد من الخدمات الدقيقة Angular المعقدة.

في صحتك!