الواجهات الخلفية لنمط الواجهات الأمامية

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

السياق والمشكلة

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

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

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

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

حل

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

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

لمزيد من المعلومات، راجع النمط: الواجهات الخلفية للواجهات الأمامية.

المسائل والاعتبارات

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

موعد استخدام النمط

استخدم هذا النمط عندما:

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

قد لا يكون هذا النمط مناسبًا:

• عندما تقوم الواجهات بإجراء نفس الطلبات أو طلبات مشابهة للواجهة الخلفية.
• عند استخدام واجهة واحدة فقط للتفاعل مع الخلفية.

تصميم حمل العمل

يجب على المهندس المعماري تقييم كيفية استخدام نمط الواجهات الخلفية للواجهة الأمامية في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:

كما هو الحال مع أي قرار تصميم، ضع في اعتبارك أي مفاضلات ضد أهداف الركائز الأخرى التي يمكن إدخالها مع هذا النمط.

الخطوات التالية

• النمط: الواجهات الخلفية للواجهات الأمامية

الموارد ذات الصلة

• نمط تجميع البوابة
• نمط إلغاء تحميل البوابة
• نمط توجيه البوابة