لقد واجهت مؤخرًا مثل هذا السيناريو للتطبيق. كانت إحدى المؤسسات تستخدم نظامًا تم تطويره بواسطة PowerBuilder لسنوات عديدة، ومع تطور الشركة، قررت تحويل نظام المعلومات القديم من C/S إلى بنية B/S الشائعة نشأت المشكلة: تحتوي بعض الأنظمة الأصلية على عدد كبير من إدخال البيانات وطباعة التقارير الدقيقة ووظائف أخرى، والمستخدمون معتادون جدًا على هذا النوع من العمليات، ومن المأمول أن يحتفظ النظام الجديد بهذه الميزة سهلة الاستخدام من النظام الأصلي.
لقد شعرت بالصداع بمجرد سماعي لهذا السؤال. لدى PB الكثير من عناصر التحكم القوية ومن الصعب جدًا نقلها إلى المتصفح واستخدام صفحات الويب لمحاكاتها.
1. لماذا يصعب على B/S توفير تجربة تفاعل جيدة للمستخدم؟
هناك العديد من المشكلات الكبرى هنا:
(1) يمكن لبروتوكول HTTP عديم الحالة
تبادل المعلومات مباشرة بين نماذج Windows من خلال الذاكرة، ولكن كأساس لـ B/S؟ اتصالات البنية بروتوكول HTTP عديم الحالة.
إذا تم اعتبار المتصفح ضيفًا وخادم الويب بمثابة فندق، فسيحدث هذا الموقف تحت إدارة بروتوكول HTTP: بغض النظر عن عدد مرات زيارة الضيف، فإن خادم الويب سيعتبره الضيف الأول. زائر الوقت. وبهذه الطريقة، يجب على الضيوف إحضار وثائق الهوية الخاصة بهم معهم في كل مرة حتى يتمكن موظفو الفندق من "التحقق من هويتهم".
يؤدي انعدام حالة بروتوكول HTTP إلى "تجاهل" خادم الويب، على الرغم من أن هذا يمكن أن يزيد من إنتاجية خادم الويب، إلا أنه يسبب مشاكل في تطوير أنظمة التطبيقات. لأنه غالبًا ما يكون هناك العديد من عمليات معالجة الأعمال في أنظمة التطبيقات، وهي بطبيعتها تدفق معلومات، أي أن البيانات الأصلية تدخل من طرف ويجب أن تخضع لمعالجة معينة عندما تخرج من الطرف الآخر، فكيف يمكن تخيل ذلك هل سيتم فقدان المعلومات في عملية الأعمال بأكملها؟ لذلك، تصبح مشاركة المعلومات بين طلبات HTTP أمرًا مزعجًا. هذه هي مشكلة "الاحتفاظ بالحالة" لطلبات HTTP. يجب على كل نظام B/S حل هذه المشكلة. فكرت مايكروسوفت في بعض "الحيل الملتوية"، مثل الاستفادة الكاملة من الحقول المخفية في صفحات ويب HTML، ومن ثم القيام ببعض الحيل على خادم الويب، لذلك لدى ASP.NET مجموعة من التقنيات للحفاظ على الحالة بين كل طلب HTTP: الجلسة، ملف تعريف الارتباط، حالة العرض، الملف الشخصي، التطبيق.
ومع ذلك، لم يتم حل المشكلة تماما. على سبيل المثال، في مربع الحوار المشترك في نظام C/S الذي يجمع معلومات إدخال المستخدم، يوجد تبادل للمعلومات بين النموذج الرئيسي ومربع الحوار (وهو مقسم إلى نوعين: مشروط وغير مشروط. مربع الحوار السابق هو غير مغلق، لا يمكن تنشيط النموذج الرئيسي). ضمن بنية B/S، نظرًا لأن كل طلب من المتصفح مستقل، يجب تنفيذ تبادل مباشر للمعلومات يشبه مربع الحوار المشروط بين نافذتي متصفح مستقلتين تعرف ماذا تفعل.
يستخدم AJAX الطريقة التالية "لمحاكاة" نموذج مشروط: "دمج" النموذج الرئيسي ومربع الحوار في نموذج واحد. مربع الحوار هو عنصر div في HTML، والذي عادةً ما يكون مخفيًا ويتم عرضه عند الحاجة إليه. تحتوي مجموعة أدوات التحكم AJAX من Microsoft على عنصر تحكم مصمم لهذه الوظيفة. هناك عدد لا يحصى من الحيل مثل هذه في تطوير B/S.
يمكن ملاحظة أن العديد من الوظائف التي يمكن تنفيذها بسهولة في C/S يصعب تنفيذها للغاية في B/S.
(2) بيئة التشغيل الخاصة -
بيئة التشغيل الأمامية لنظام B/S للمتصفح هي المتصفح، الذي يفرض العديد من القيود، ولا يمكنه القيام بالعديد من الأشياء، مثل الوصول المباشر إلى الأجهزة (مثل الطابعات)، ولا يمكنه إكمالها استخدام موارد الأجهزة. على سبيل المثال، أجهزة الكمبيوتر الجديدة اليوم كلها ثنائية النواة. هل يمكنك استخدام JavaScript وHTML مباشرة لكتابة برنامج متعدد الخيوط لتحقيق الاستفادة الكاملة من هذين "نواة Pentium"؟
يعمل نظام C/S مباشرة على نظام التشغيل (OS). النظام) أعلاه، يمكنك استدعاء جميع الوظائف التي يوفرها نظام التشغيل، وهذا القيد غير موجود.
(3) لغة برمجة عميل الويب المحرجة -
يمكن لـ JavaScript، وهو برنامج C/S تقليدي، استخدام عدد كبير من لغات التطوير المختلفة، وخاصة اللغات الموجهة للكائنات السائدة مثل C++ وJava وC#، وهي قوية وسهلة الاستخدام، وأدوات التطوير المختلفة متاحة وناضجة للغاية.
على العكس من ذلك، جافا سكريبت، لغة البرمجة الأكثر استخدامًا في الواجهة الأمامية B/S، ليست فقط غير مرغوب فيها، بل حتى "مكروهة" من قبل العديد من المبرمجين، الذين يعتبرون "البرمجة باستخدام جافا سكريبت" بمثابة عمل روتيني.
دعونا نلقي نظرة على اثنين من أوجه القصور الرئيسية في جافا سكريبت.
أولا، هناك نقص في نموذج البرمجة الواضح والموحد.
على الرغم من أن جافا سكريبت تحتوي على Java في اسمها وتستخدم بناء جملة مشابهًا، إلا أنها لا علاقة لها بجافا الحقيقية. للأسف، إنها بطة قبيحة، فهي تريد دائمًا أن تصبح بجعة، لكنها لا تتوقع ألا يشتري الآخرون فكرتها.
تستخدم JavaScript العديد من الكائنات، ولكن من غير المقنع حقًا القول إنها موجهة للكائنات (الوحدة الأساسية للبرمجة الموجهة للكائنات هي فئة)، على سبيل المثال، لا تحتوي على فئة الكلمات الرئيسية المشابهة للغات الموجهة للكائنات السائدة مثل C#، فهي تعمل في كل مكان واحدة تلو الأخرى، مما يجعل من الصعب تحديد جميع الأكواد بشكل واضح في شكل فئات، وفي نفس الوقت، فهي غير منظمة (الوحدة الأساسية للبرمجة المنظمة هي وظيفة )، لأن المتصفح يستخدم دفقًا عند تحليل مستندات HTML، مما يؤدي إلى وضع بعض تعليمات JavaScript البرمجية خارج الوظيفة وتنفيذها مباشرةً عند تحليل مستند HTML، بينما يتم تشغيل الجزء الآخر من التعليمات البرمجية الموضوعة في الوظيفة في الغالب في حدث ما. الطريقة الموجهة، والتي تؤدي إلى مشاكل معقدة، يكون تدفق تنفيذ البرنامج أقل إيجازًا بكثير من الاستخدام الموحد لاستدعاءات الوظائف في البرمجة المنظمة البحتة.
من وجهة النظر هذه، تتمتع JavaScript بخصائص أساليب البرمجة الموجهة للكائنات والمنظمة وغير المنظمة، ولكنها ليست سمكة ولا طيرًا، ولا تحتوي على نموذج برمجة واضح وموحد، ومن الصعب كتابة تعليمات برمجية واضحة جاء الهيكل وسهولة الصيانة.
ثانيًا، هناك عيب آخر في JavaScript وهو بيئة تشغيل المتصفح.
لأسباب تاريخية، تحتوي المتصفحات المختلفة، وحتى الإصدارات المختلفة من نفس المتصفح، على نماذج برمجة مختلفة إلى حد ما، لذلك يتعين علينا كتابة التعليمات البرمجية لاكتشاف نوع المتصفح، على سبيل المثال، نحتاج إلى كتابة مجموعة من التعليمات البرمجية IE، وكتب مجموعة أخرى لفايرفوكس. هذا هو حقا متاعب.
المشاكل المذكورة أعلاه هي تقريبًا "العيوب" "المتأصلة" في نظام هندسة B/S. يتم استكمال أوجه القصور الفطرية بالتنشئة، وقد توصل الناس إلى العديد من الحيل لحل هذه المشاكل. أجاكس هو نجم الأمل الذي يتفائل به الجميع.
2. نجمة الأمل – AJAX
خلال الأيام القليلة الماضية، تعلمت بشكل منهجي عن إطار عمل AJAX الخاص بشركة Microsoft. لقد وجدت أن تعقيد هذا الإطار تجاوز بكثير تقديري الأصلي. لقد استكشف مهندسو Microsoft الذين صمموا إطار عمل AJAX بعمق إمكانات تقنيات تطوير الويب المختلفة، والتي عوضت إلى حد كبير عن المشكلات التي أثيرت سابقًا.
(1) توسيع لغة جافا سكريبت:
قامت مايكروسوفت بتعزيز ميزات جافا سكريبت الموجهة للكائنات من خلال توفير مكتبة AJAX مغلفة، والتي يمكنها بسهولة تنفيذ وظائف مثل الوراثة، وتحديد الواجهات، وتسلسل الكائنات، وإطلاق الأحداث، وأنواع الانعكاس، وما إلى ذلك، على الرغم من أنها أصغر من الحقيقية، لا تزال هناك فجوة بين اللغات الموجهة للكائنات (مثل Java/C#)، ولكن القدرة على تلبيس جافا سكريبت "القبيحة" إلى شيء مرئي يعتبر أمرًا استثنائيًا.
(2) تحسين وظائف التعليمات البرمجية من جانب المتصفح بشكل كبير،
بدعم من مكتبة AJAX والوظائف المحسنة لـ JavaScript، وبدعم من المتصفح نفسه، يمكنك كتابة نصوص JavaScript النصية في المتصفح لتقديم طلبات غير متزامنة بسهولة إلى المتصفح. الخادم، وتحقيق تحديث جزئي للصفحة، ويمكنه الاتصال بخدمة الويب مباشرة.
(3) كان تقديم طريقة التطوير القائم على المكونات (CBD
) هو أسلوب التطوير السائد للأنظمة الموجهة للكائنات منذ فترة طويلة، على الرغم من أن SOA (الهندسة القائمة على الخدمة) تحظى بشعبية كبيرة حاليًا، إلا أنها تحتاج إلى ذلك سوف يستغرق الأمر بعض الوقت للوصول إلى مرحلة النضج في اتفاقية التنوع البيولوجي.
بالنسبة لجافا سكريبت، ناهيك عن SOA، من الصعب جدًا تنفيذ اتفاقية التنوع البيولوجي.
من أجل تحقيق اتفاقية التنوع البيولوجي، أجرت Microsoft "تحسينات كبيرة" على JavaScript وعززت العديد من الميزات. استنادًا إلى مكتبة Microsoft AJAX، يمكن للمبرمجين تطوير ثلاثة أنواع من المكونات القابلة لإعادة الاستخدام: مكون غير مرئي (مكون غير مرئي، يعادل النظام الموجه للكائنات). منها توفر وظائف عامة)، والسلوك (السلوك، وتوسيع وظائف عناصر التحكم الموجودة على الويب)، والتحكم (عناصر تحكم الويب مع عناصر الواجهة المرئية).
على وجه الخصوص، تحقق العشرات من عناصر التحكم المتوفرة في AJAX Control ToolKit بشكل أساسي محاكاة B/S لمعظم ميزات واجهة مستخدم C/S، وهي نموذج لتطبيق نموذج البرمجة الجديد هذا.
إن تحسينات مايكروسوفت لنموذج برمجة جافا سكريبت تمكن مهندسي البرمجيات من تطوير كود عميل الويب باستخدام أساليب تطوير اتفاقية التنوع البيولوجي. أعتقد أن هذا هو التقدم.
(4) قدرات محسنة من جانب الخادم
من أجل تعزيز قدرات الكود من جانب المتصفح، يجب تنسيقه من خلال جانب الخادم. يعتمد AJAX نفسه على نموذج البرمجة الذي يدعم فيه المتصفح وخادم الويب بعضهما البعض (يوفر خادم الويب خدمات البيانات، ويوفر المتصفح كائنات XMLHttpRequest لإصدار طلبات غير متزامنة إلى خادم الويب. وعندما تعود البيانات، يمكن للمبرمجين كتابة التعليمات البرمجية في JavaScript إلى تنفيذ المعالجة الجزئية الديناميكية لتجديد صفحات الويب).
من خلال ملحق AJAX، قامت Microsoft بتحسين وظائف إطار عمل ASP.NET من جانب الخادم. وقم بإضفاء الطابع الخارجي على الوظائف الشائعة الاستخدام في عناصر تحكم ويب بسيطة، مثل ScriptManager للتحكم الأساسي في AJAX، وUpdatePanel لتحديد المناطق القابلة للتحديث في الصفحة، والعشرات من أدوات التحكم في AJAX لتحسين عناصر تحكم ASP.NET الحالية (أي عنصر تحكم مرتبط بـ عنصر تحكم موجود، والغرض منه هو توسيع وظائف جديدة لعنصر التحكم الموجود).
باستخدام عناصر التحكم هذه، يكون تطوير برامج الواجهة الأمامية للويب مشابهًا لتصميم النماذج في لغة VB. الآن، ليس من الممكن فقط رسم واجهة مشابهة لـ Windows Forms، ولكن أيضًا باستخدام طلب AJAX غير المتزامن وتقنية التحديث الجزئي للصفحة، وبالتعاون مع خادم الويب، يمكن فرض تجربة المستخدم في Windows Forms.
بغض النظر عن عدد الأشخاص الذين ينظرون بازدراء إلى VB، فإن موجة تعميم البرمجة المرئية التي جلبتها VB كان لها بالفعل تأثير بعيد المدى، كما أن دفع Microsoft لبرمجة JavaScript إلى هذه الخطوة هو أيضًا الاتجاه العام. ومن أجل تحسين كفاءة تطوير الويب، يجب اتخاذ هذه الخطوة.
ومع ذلك، تجدر الإشارة إلى أنه بغض النظر عن مقدار "تجديدها"، فهي في النهاية "ناقصة خلقيًا" ولا يزال من الصعب جدًا على بنية B/S تجاوز C/S من حيث تجربة المستخدم .
3. المستقبل: B/S أو C/S، من المسؤول؟
نظرًا لبساطة الإدارة والنشر، أصبحت بنية B/S هي الخيار الأول للعديد من أنظمة المعلومات اليوم، ومع ذلك، يسعى المستخدمون إلى الحصول على مستخدم جيد الخبرة وخلاصة القول، هناك المتطلبات التالية:
(1) واجهة جميلة. تتمتع B/S بميزة في هذا الصدد.
(2) مدخلات مريحة. على سبيل المثال، يأمل العديد من المستخدمين في إدخال البيانات دون استخدام الماوس، أو ملء البيانات تلقائيًا من خلال نقرات بسيطة، وهذا أمر يصعب تنفيذه في ظل بنية B/S، ويمكن أن يحل هذه المشكلة إلى حد ما.
(3) سرعة البرق. بالنسبة لـ C/S، هناك العديد من الطرق لتحقيق سرعة استجابة سريعة، لكن الأمر ليس سهلاً بالنسبة لـ B/S. نظرًا لقيود المتصفح، فإن موارد الأجهزة القوية للعميل تكاد تكون خاملة. بالإضافة إلى ذلك، فإن سرعة الشبكة هي عنق الزجاجة في بنية B/S وما لم يكن من الممكن زيادة عرض النطاق الترددي بسرعة، فستكون شبكة WWW بمثابة انتظار عالمي.
على الرغم من أن C/S تتمتع بتجربة مستخدم جيدة، إلا أن مشكلتها تكمن في صعوبة تطوير نظام موزع يمتد عبر الإنترنت بالكامل، علاوة على ذلك، نظرًا لأن العميل يحتاج إلى التثبيت، تصبح تحديثات النظام وإدارة إصدار المكونات مشكلة كبيرة بالإضافة إلى ذلك، على عكس B في بنية /S، يجب مراعاة المشكلات من جانب الخادم فقط. في بنية C/S، نظرًا لوصول العديد من المستخدمين إلى الخادم في نفس الوقت، تكون الاستدعاءات والتبعيات بين مكونات العميل معقدة يجب أيضًا أخذها في الاعتبار عند التعامل مع الوصول متعدد الخيوط إلى الموارد المشتركة ومعالجة المعاملات وما إلى ذلك. مع جانب الخادم، تكون الإنتاجية محدودة إلى حد كبير. لذلك، يتم إنشاء C/S في الغالب في الشبكة المحلية للاستخدام الداخلي للمؤسسة.
في الوقت الحاضر، تتعايش B/S وC/S بشكل أساسي مع التطبيق الواسع النطاق لتقنيات B/S مثل AJAX، وتستمر B/S في اكتساب اليد العليا، ولكن من المستحيل "هزيمة C/S" تمامًا. .
الأمر الأكثر إثارة للاهتمام هو: كيف تنظر شركة كبيرة مثل Microsoft إلى آفاق تطوير B/S وC/S؟
لا تتاح للمطورين العاديين مثلي الفرصة للتحدث مباشرة مع المسؤولين التنفيذيين في Microsoft، ولكن يمكننا رؤية ذلك من خلال الشركة؟ وفيما يلي بعض الدلائل:
لا يبدو أن شركة ميكروسوفت تعتقد أن نظام B/S يمثل الاتجاه المستقبلي للتطور التكنولوجي، بل على العكس من ذلك، فإن العديد من تصرفاتها تتحرك في اتجاه التخلي عن المتصفحات.
بادئ ذي بدء، قامت Microsoft بتبسيط تطوير ونشر C/S وأطلقت تقنية Smart Client، بحيث يمكن إجراء تحديث برامج عملاء C/S تلقائيًا دون تدخل يدوي.
ثانيًا، عملت Microsoft جاهدة على سد الفجوة بين B/S وC/S عند تصميم ASP.NET، تخلت بحزم عن ASP، الذي حقق نتائج جيدة، واعتمدت بشكل مباشر أسلوب البرمجة المماثل "التحكم المرئي + المبني على الأحداث". إلى VB حتى صفحات الويب تسمى "نماذج" - نماذج الويب.
ثالثًا، قد تعتبر Microsoft أن AJAX هي تقنية انتقالية.
كانت Microsoft بطيئة في اتخاذ إجراء بشأن AJAX حتى شهدت الشعبية السريعة لـ AJAX بسبب التطبيق الناجح لتقنية AJAX من قبل Google والشركات الأخرى لتحسين تجربة مستخدم الويب، ثم اتخذت إجراءً وأضفت امتدادات AJAX إلى ASP.NET من الواضح أن العملية برمتها لم تكن عدوانية، ولم يتم استثمار الكثير من الموارد، وكان هذا مختلفًا تمامًا عما حدث عندما أطلقت Microsoft وNetscape حرب المتصفحات. ومع ذلك، فإن حقيقة أنها تحتوي على ملحق AJAX كتكوين قياسي في VS2008 ودمج وظيفة تصحيح أخطاء JavaScript مباشرة في IDE تظهر أن Microsoft لا تزال تواجه الواقع وتدرك أن AJAX يتمتع بمكانة مهمة وإمكانات تطوير كبيرة.
في الواقع، أعتقد أن طموح مايكروسوفت هو "توحيد العالم"، والتخلي عن المتصفح، وتوحيد B/S وC/S بالكامل.
يظهر هذا بوضوح في .NET 3.0/3.5.
بادئ ذي بدء، استخدمت Microsoft WCF لتوحيد DCOM و.NET Remoting والتقنيات الأخرى المستخدمة بشكل أساسي لـ C/S، ودمج العديد من ميزات تطوير المؤسسات الموجودة في الأصل في COM+، جنبًا إلى جنب مع تقنية خدمة الويب المستخدمة بشكل أساسي لهندسة B/S، لتوحيد الملخص وتغليفها في خدمة WCF قابلة لإعادة الاستخدام. من الواضح أن Microsoft تريد تغيير نموذج تطوير نظام المعلومات من اتفاقية التنوع البيولوجي إلى SOA (أي أن الأنظمة المستقبلية ستقوم بتجميع الخدمات بدلاً من المكونات).
ثانيًا، تخلت Microsoft عن نموذج برمجة برامج سطح المكتب Window الناضج جدًا (Win32 API + برنامج تشغيل الرسائل/الأحداث) وقدمت إطار برمجة WPF جديدًا، وهو ظهور XAML (لغة ترميز التطبيقات) التي تتوافق مع مواصفات XML. . يستخدم XAML ملفات نصية عادية بتنسيق XML لوصف واجهات التطبيق.
يمكننا بسهولة مقارنة XAML بـ XHTML. يقوم المتصفح بتحليل كود XHTML وإنشاء واجهة ويب مرئية، بينما يتم تحليل XAML بواسطة الجهاز الظاهري .NET Framework XAML لإنشاء واجهة المستخدم وتنفيذ جميع وظائف التطبيق الخاصة به.
ونتيجة لذلك، ظهر نموذج برمجة جديد، سواء كان نظام B/S أو C/S، فإن الطريقة موحدة: قراءة كود XAML ثم التحليل ثم الحاضر ثم تلقي مدخلات المستخدم ثم معالجة البيانات ثم عرضها.
في نموذج البرمجة هذا، يصبح المتصفح متفرجًا ولم يعد جوهر تطبيق العميل.
يعمل نموذج البرمجة الجديد على نظام تشغيل كامل المواصفات بدلاً من متصفح ذي وظائف محدودة. الفرق كبير. كيف يمكن مقارنة وظائف المتصفح الذي يعمل على نظام التشغيل مع نظام التشغيل نفسه!
الآن يمكن استدعاء نظام التشغيل بسهولة من خلال واجهة برمجة التطبيقات (API) لنظام التشغيل، بطريقة موجهة للكائنات وظائف لتحقيق الاستفادة الكاملة من موارد أجهزة العميل (على سبيل المثال، يمكنك بسهولة تطوير برامج متعددة الخيوط أعلى .NET Framework "للضغط" على قدرات العمل لوحدة المعالجة المركزية ثنائية النواة). يتم وصف جميع واجهات المستخدم باستخدام XAML، الذي يوحد تقنيات طبقة الواجهة لـ B/S وC/S.
بيئة التشغيل الأكثر ملائمة لـ WPF هي نظام التشغيل Vista. يتم تنفيذ مجموعة فرعية من وظائفه، والتي تسمى الآن Silverlight، كمكون إضافي للمتصفح، مما يسمح بتشغيل برامج WPF في المتصفحات التقليدية. نظرًا لأن كلاً من Silverlight وVista يستطيعان تحليل XAML بأنفسهما، يمكنك الآن استخدام XAML لكتابة مجموعة واحدة فقط من أكواد الواجهة، والتي تنطبق على كل من B/S وC/S وتحصل على نفس تجربة المستخدم.
نظرًا لبعض أوجه القصور المتأصلة في B/S وAJAX، إذا تمت مقارنة نظام B/S المعزز بواسطة AJAX براقصة، فهي في الواقع راقصة ترقص بالأغلال، وفكرة Microsoft هي، بدلاً من محاولة تقليل الوزن باستمرار لماذا لا نتخلى عن هذا القيد ببساطة؟
يعد إطلاق Microsoft لـ WPF وWCF بمثابة محاولة من هذا القبيل.
تجدر الإشارة إلى أن استراتيجية التطوير التي تتبعها Microsoft تعتمد على تحليل مزايا وعيوب B/S وC/S الحالية، ولها طبيعتها العلمية وتأخذ في الاعتبار أيضًا مصالحها التجارية الخاصة. ومع ذلك، لا تزال هناك صعوبات كثيرة في تحقيق هذه الاستراتيجية، لأنه حتى مع قوة مايكروسوفت، إلا أنها لا تستطيع السيطرة على العالم. إن خصوم مايكروسوفت يتمتعون بنفس ذكاء مايكروسوفت، كما أن التكنولوجيا الخاصة بهم تتقدم بنفس السرعة.
يمكن الاستنتاج أنه نظرًا لاستمرارية تطبيقات نظام المعلومات، فإن B/S وC/S سوف يتعايشان في نفس الوقت لفترة طويلة من الزمن (ربما من ثلاث إلى خمس سنوات، وربما من خمس إلى عشر سنوات). سوف تسود العديد من الميزات الممتازة المتميزة لـ B/S في المنافسة مع C/S، ولن يتغير هذا الوضع بشكل كبير. أما بالنسبة لـ AJAX، فهو سلاح ثقيل الوزن في نظام B/S، وعلى الرغم من فعاليته الكبيرة، إلا أنه به العديد من العيوب، وأنا متفائل بحذر بشأن تطوره المستقبلي، ومع ذلك، كمطور ويب، يجب عليك فهم هذه التكنولوجيا وتطبيقها.
إن الشكل الذي سيبدو عليه المشهد المستقبلي، وما إذا كان لتقنية معينة مستقبل، لا يقرره الأفراد. أعتقد أن النمط النهائي للمعركة بين B/S وC/S سيكون نتيجة للعبة المشتركة بين عوامل متعددة. بالنسبة للأفراد، يجب عليهم مواكبة العصر وتعديل إجراءاتهم واستراتيجياتهم في الوقت المناسب. هذا هو مصير مطوري البرمجيات المعاصرين.