مقدمة
في السنوات الأخيرة ، كان التكيف متعدد الطرفي المستندة إلى المواقع المختلفة على قدم وساق ، كما تم تطوير حلول تعتمد على التقنيات المختلفة بين الصناعات. مثل التصميم المستجيب القائم على استعلام Media Media الأصلي للمتصفح ، وحل "التكيف السحابي" يعتمد على إعادة ترتيب السحابة الذكية ، وما إلى ذلك. تناقش هذه المقالة بشكل أساسي حلول التكيف متعددة الطرفي بناءً على فصل نهايات الأمام والخلفية.
حول فصل الواجهة الأمامية
فيما يتعلق بحل الفصل الأمامي ، هناك تفسير واضح للغاية في "التفكير وممارسة الفصل الأمامي على أساس NodeJS (I)". قدمنا Nodejs كطبقة عرض بين واجهة الخادم والمتصفح. نظرًا لأن طبقة NodeJS مفصولة تمامًا عن البيانات ولا تحتاج إلى الاهتمام بالكثير من منطق العمل ، فهي مناسبة جدًا لأعمال التكيف متعددة الطرفي في هذه الطبقة.
اكتشاف UA
أول شيء يتم حله في التكيف متعدد الطرفي هو مشكلة اكتشاف UA. للحصول على طلب أكثر ، نحتاج إلى معرفة نوع هذا الجهاز لإخراج المحتوى المقابل إليه. يوجد الآن مكتبة ميزة وكيل مستخدم ناضجة للغاية وأدوات اكتشاف متوافقة مع عدد كبير من الأجهزة في السوق. فيما يلي قائمة تم تجميعها بواسطة Mozilla. من بينها ، هناك كلاهما يعملان على جانب المتصفح وتلك التي تعمل على طبقة رمز جانب الخادم. توفر بعض الأدوات حتى وحدات NGINX/Apache ، والتي تكون مسؤولة عن تحليل معلومات UA لكل طلب.
في الواقع نوصي آخر واحد. يحدد الحل القائم على الفصل الأمامي أن مسبار UA لا يمكن أن يعمل إلا على جانب الخادم ، ولكنه ليس حلاً ودود بما فيه الكفاية إذا تم ربط رمز التحقيق ومكتبة الميزات في رمز العمل. ننقل هذا السلوك إلى الأمام ونعلقه على Nginx/Apache. إنهم مسؤولون عن تحليل معلومات UA لكل طلب ثم نقله إلى رمز العمل من خلال HTTP Header.
هناك العديد من الفوائد للقيام بذلك:
لم يعد الرمز الخاص بنا يحتاج إلى الانتباه إلى كيفية تواجد UA ، ما عليك سوى إخراج المعلومات المحسورة من الطبقة العليا. إذا كانت هناك تطبيقات متعددة على نفس الخادم ، فيمكن استخدام معلومات UA التي يتم تحليلها بواسطة نفس Nginx معًا ، مما يوفر فقدان الدقة بين التطبيقات المختلفة.
حل الكشف عن UA استنادًا إلى NGINX المشتركة بواسطة TMALL
يوفر خادم الويب Tengine Tengine Taobao أيضًا وحدة نمطية مماثلة NGX_HTTP_USER_AGENT_MODULE.
تجدر الإشارة إلى أنه عند اختيار أدوات اكتشاف UA ، يجب النظر في قابلية صيانة مكتبة الميزات. نظرًا لوجود المزيد والمزيد من أنواع المعدات الجديدة في السوق ، سيكون لكل جهاز وكيل مستخدم مستقل ، لذلك يجب أن توفر مكتبة الميزات استراتيجيات تحديث وصيانة جيدة للتكيف مع المعدات المتغيرة.
عدة تعديلات مدمجة في وضع MVC
بعد الحصول على معلومات UA ، نحتاج إلى النظر في ما إذا كان يتم تنفيذ التكيف الطرفي بناءً على UA المحدد. حتى في طبقة NodeJS ، على الرغم من أن معظم منطق العمل مفقود ، إلا أننا لا نزال نقسم الأجزاء الداخلية إلى ثلاثة نماذج: Model/Controller/View.
دعنا نستخدم أولاً الرسم البياني أعلاه لتحليل بعض حلول التكيف المتعددة المحطات.
التعديلات المبنية على وحدة التحكم
يجب أن يكون هذا الحل أبسط وأكثر الطرق فظًا للتعامل معه. تمرير عنوان URL نفسه إلى طبقة التحكم نفسها من خلال جهاز التوجيه. تقوم طبقة التحكم بعد ذلك بتوزيع البيانات ومنطق النموذج على الشاشة المقابلة (عرض) من خلال معلومات UA لتقديمها ، وتوفر طبقة التقديم قوالب تتكيف مع العديد من المحطات المحطات وفقًا للمهاريات المسبقة.
تتمثل ميزة هذا الحل في أنه يحافظ على وحدة طبقات البيانات وطبقات التحكم ، ويمكن تطبيق منطق العمل على جميع المحطات المحطات مرة واحدة فقط. ومع ذلك ، فإن هذا السيناريو مناسب فقط للتطبيقات المنخفضة التفاعل مثل صفحات العرض. بمجرد أن يصبح العمل أكثر تعقيدًا ، قد يكون لوحدات التحكم في كل محطة منطق معالجة خاص بها. إذا كانوا لا يزالون يشاركون وحدة التحكم ، فسيجعل وحدة التحكم متضخمة للغاية ويصعب الحفاظ عليها ، وهو بلا شك خيار خاطئ.
التعديلات المبنية على جهاز التوجيه
من أجل حل المشكلات المذكورة أعلاه ، يمكننا التمييز بين الأجهزة على جهاز التوجيه وتوزيعها على وحدات تحكم مختلفة لمحطات مختلفة:
هذا أيضًا أحد الحلول الأكثر شيوعًا ، التي تتجلى في الغالب في استخدام مجموعة منفصلة من التطبيقات لمحطات مختلفة. على سبيل المثال ، عندما يزور جهاز PC Taobao Homepage وإصدار WAP من صفحة Taobao الرئيسية ، عندما تقوم أجهزة مختلفة بزيارة www.taobao.com ، سيعيد الخادم توجيهًا إلى إصدار WAP من الصفحة الرئيسية Taobao أو إصدار الكمبيوتر الشخصي من Taobao Homepage من خلال التحكم في جهاز التوجيه. وهما مجموعتان مستقلتان تمامًا من التطبيقات.
ومع ذلك ، فإن هذا الحل لا شك في أن المشكلة التي لا يمكن مشاركة البيانات وجزء من المنطق. لا يمكن للمحطات المختلفة مشاركة نفس البيانات ومنطق الأعمال ، مما يؤدي إلى الكثير من العمل المتكرر وغير فعال.
من أجل تخفيف هذه المشكلة ، اقترح شخص ما حلًا محسّنًا: في نفس المجموعة من التطبيقات ، لا يزال كل مصدر بيانات يتم تجريده في كل نموذج ، ويتم توفيره إلى وحدات التحكم في المحطات المختلفة للمجموعة:
يحل هذا الحل المشكلة التي لا يمكن مشاركة البيانات السابقة. على وحدة التحكم ، لا تزال كل محطة مستقلة عن بعضها البعض ، ولكن يمكنها استخدام نفس مجموعة مصادر البيانات معًا. على الأقل ليست هناك حاجة لتطوير واجهات مستقلة لأنواع الطرفية في البيانات.
في الحلتين المذكورتين أعلاه ، نظرًا لاستقلال وحدة التحكم ، يمكن لكل محطة تنفيذ منطق تفاعلي مختلف لصفحاته الخاصة ، مما يضمن مرونة كافية لكل محطة نفسها ، وهو السبب الرئيسي أيضًا لتبني معظم التطبيقات هذا الحل.
التعديلات المبنية على طبقة العرض
هذا هو الحل المستخدم في صفحات طلب Taobao ، ولكن الفرق هو أن صفحة الطلب تضع طبقة العرض الإجمالية على جانب المتصفح ، بدلاً من طبقة NodeJS. ومع ذلك ، سواء كان متصفحًا أو NodeJs ، فإن فكرة التصميم الكلية لا تزال كما هي:
في هذا الحل ، لا يحتاج جهاز التوجيه ووحدة التحكم والنموذج إلى الانتباه إلى معلومات الجهاز ، ويتم ترك حكم النوع الطرفي تمامًا إلى طبقة العرض للمعالجة. الوحدة الرئيسية في الشكل هي "عرض المصنع". بعد مرور النموذج ووحدة التحكم على البيانات وتقديم منطق ، يستخدمون مصنع العرض للاستيلاء على مكونات محددة من مجموعة من المكونات المسبقة المسبقة بناءً على معلومات الجهاز وحالات أخرى (ليس فقط معلومات UA ، ولكن أيضًا بيئة الشبكة ، منطقة المستخدم ، وما إلى ذلك) ثم دمجها في الصفحة النهائية.
هذا الحل له العديد من المزايا:
لا تحتاج الطبقة العليا إلى الانتباه إلى معلومات الجهاز (UA). لا يزال يتم التعامل مع مقاطع الفيديو الخاصة بمحطات متعددة بواسطة طبقة العرض التي تظهر في النهاية أكبر علاقة. إنه ليس مجرد تكيف متعدد الطرفي ، ولكن بالإضافة إلى معلومات UA ، يمكن لكل مكون عرض أيضًا تحديد النموذج الذي يخرجه وفقًا لحالة المستخدم ، مثل إخفاء الصور افتراضيًا في سرعات الشبكة المنخفضة ولافتات النشاط المخرج في المناطق المحددة. يمكن أن تقرر قوالب مختلفة من كل مكون عرض ما إذا كنت تريد استخدام نفس البيانات والمنطق التجاري وفقًا لتقديرك ، مما يوفر طريقة تنفيذ مرنة للغاية.
ولكن من الواضح أن هذا الحل هو أيضًا الأكثر تعقيدًا ، خاصة عند النظر في بعض سيناريوهات التطبيق التفاعلية ، قد لا يكون جهاز التوجيه ووحدة التحكم قادرين على البقاء نقيًا للغاية. خاصة بالنسبة لبعض الشركات ذات النزاهة القوية نسبيًا ، والتي لا يمكن تقسيمها إلى مكونات نفسها ، قد لا يكون هذا الحل قابلاً للتطبيق ؛ وبالنسبة لبعض الشركات البسيطة ، قد لا يكون استخدام هذه البنية هو الخيار الأفضل.
لخص
تنعكس كل الحلول المذكورة أعلاه في جزء واحد أو أكثر من نموذج MVC. إذا لم يستوف أحد الحلول الاحتياجات في الأعمال ، فيمكن اعتماد حلول متعددة في نفس الوقت. أو يمكن فهم أن التعقيد والسمات التفاعلية في العمل يحدد حل التكيف متعدد الطرفية الذي يكون المنتج أكثر ملاءمة له.
بالمقارنة مع نظام التصميم المستجيب المستند إلى المتصفح ، نظرًا لأن معظم المنطق في الكشف الطرفي وتقديمه يتم ترحيله إلى الخادم ، فإن التكيف مع طبقة NodeJS يجلب بلا شك أداء أفضل وتجربة مستخدم ؛ بالإضافة إلى ذلك ، بالمقارنة مع مشاكل جودة التحويل التي تسببها بعض مخططات "التكيف السحابي" المزعوم ، فلن تكون موجودة في مخطط "مخصص" استنادًا إلى الفصل الأمامي. إن حل التكيف لفصل الأطراف الأمامية والخلفية له مزايا طبيعية في هذه الجوانب.
أخيرًا ، من أجل التكيف مع احتياجات التكيف الأكثر مرونة وقوية ، ستواجه حلول التكيف القائمة على الفصل الأمامي المزيد من التحديات!