شركة كومورا سوفت ذ.م.م.
تواصل معنا
القائمة

متى لا يُفضَّل تحويل تطبيق Windows إلى الويب: جدول القرار وحل «التقسيم» الواقعي

· · تطوير Windows, الانتقال إلى الويب, التحديث والتطوير, تطبيقات الأعمال, جدول القرار, التصميم, الاستشارة التقنية

«حان الوقت لتحويل تطبيق Windows الذي نستخدمه داخلياً إلى الويب» - هذا النوع من الطلبات يتزايد عاماً بعد عام. وغالباً ما يكون الدافع وراءه معقولاً، لكن عند التعمّق في التفاصيل، نجد في كثير من الأحيان حالات تسعى إلى تحويل تطبيق بالكامل إلى الويب رغم أن ذلك سيجعله أصعب استخداماً وأعلى تكلفة.

لتوضيح الأمر منذ البداية: هذا المقال ليس دعوة إلى «عدم التحويل إلى الويب على الإطلاق». فهناك كثير من الحالات التي يكون فيها التحويل إلى الويب هو الخيار الصحيح بوضوح، مثل الاستخدام من عدة مواقع أو تقليل إدارة الأجهزة الطرفية. المشكلة هي معاملة جميع التطبيقات على قدم المساواة، وافتراض أن «التحديث = التحويل إلى الويب» حتى مع التطبيقات التي لا تناسبها طبيعتها هذا التحويل. يستعرض هذا المقال طريقة التمييز التي نستخدمها فعلياً في ميدان تطوير تطبيقات Windows بالتعاقد لتحديد «الحالات التي يُفضَّل فيها عدم التحويل إلى الويب»، كما يقدّم حل التقسيم كبديل واقعي يتجاوز الخيار الثنائي بين التحويل الكامل إلى الويب أو الإبقاء الكامل على Windows.

1. الاستنتاج أولاً (جدول القرار)

المهم هو الحكم ليس على التطبيق ككل، بل على كل وظيفة أو خاصية يمتلكها التطبيق على حدة.

خاصية التطبيق التوافق مع التحويل إلى الويب السبب
الرجوع إلى البيانات نفسها من عدة مواقع أو من خارج الشركة ◎ مناسب يكفي وجود متصفح، ولا حاجة إلى التثبيت على الأجهزة
التركيز على العرض والبحث والتجميع والتقارير ◎ مناسب يمكن تحقيقه بوظائف المتصفح القياسية، وهو مجال تتفوّق فيه واجهات الويب
تغيير الأجهزة أو زيادتها ونقصانها بشكل متكرر ○ مناسب لا حاجة إلى توزيع على العميل، وتقلّ أعمال إعداد الأجهزة (kitting)
التواصل المباشر مع أجهزة serial أو USB وأجهزة القياس ومعدّات التصنيع × غير مناسب صندوق العزل (sandbox) الخاص بالمتصفح يقيّد الوصول إلى الموارد المحلية1
مراقبة الملفات المحلية ومعالجتها دفعة واحدة، والتواصل بين العمليات مع تطبيقات أخرى (مثل Excel) × غير مناسب لا يمكن للمتصفح الوصول الحر إلى الملفات أو تشغيل عمليات أخرى
الاستخدام في مهام لا يمكن أن تتوقف، في مواقع ذات شبكة غير مستقرة × غير مناسب وظائف تطبيقات الويب تكون محدودة جداً في وضع عدم الاتصال2
التركيز على الإدخال السريع والكبير الحجم عبر لوحة المفاتيح بشكل أساسي △ يتطلّب حذراً تأخّر الاستجابة في كل عملية، وتكلفة إعادة إنتاج شبكات بيانات (grids) بجودة سطح المكتب، مشكلتان متوقّعتان
لا يوجد دافع للتحويل إلى الويب سوى «كون التقنية قديمة» △ يتطلّب حذراً التحويل إلى الويب استثمار أقرب إلى إعادة البناء الكاملة؛ فإذا كان الدافع الوحيد هو قِدَم التقنية أو حداثتها، فينبغي مقارنته بالتحديث مع الإبقاء على التطبيق كتطبيق Windows

وفيما يلي الخلاصة مقدَّمةً:

  • غالباً ما تختلط في طلب «نريد التحويل إلى الويب» ثلاث مشكلات مختلفة، وهي: عناء التوزيع، والقيود على مكان الاستخدام، والتقادم التقني. لكل منها حل مختلف، والتحويل إلى الويب ليس الحل الوحيد إلا لبعض هذه المشكلات (الفصل 2).
  • التطبيقات التي تتضمّن تكاملاً مع الأجهزة أو معالجة ملفات محلية أو عملاً دون اتصال، من الأسلم عدم تحويل تلك الأجزاء إلى الويب. فالمتصفحات تُقيّد الوصول إلى الموارد المحلية عمداً لأسباب أمنية، وهذا ليس عيباً في تقنية الويب بل هو فلسفة تصميم مقصودة1. وحتى لو وُجدت طرق للالتفاف على هذا القيد، فإنها تجلب تكاليف أخرى، مثل محدودية دعم المتصفحات وتعقيد التشغيل (الفصول 3 إلى 5).
  • التحويل إلى الويب ليس «نقلاً» بل «إعادة بناء». فأصول الشاشات الحالية لا يمكن نقلها كما هي، وبعد الانتهاء ستنشأ تكلفة مستمرة جديدة تتمثّل في تشغيل الخادم. وإذا لم يُبنَ التقدير على هذا الأساس، فسينهار المخطط في منتصف الطريق (الفصل 7).
  • الحل الواقعي هو التقسيم. ضَع العرض والتجميع والتقارير على الويب، وأبقِ التكامل مع الأجهزة والإدخال الميداني على Windows، ثم اربط الجزأين عبر واجهة برمجة تطبيقات وقاعدة بيانات مشتركتين. بهذه الطريقة يمكن البدء بنطاق أصغر من التحويل الكامل إلى الويب، والتقدّم تباعاً بدءاً من الأجزاء الأكثر فائدة (الفصل 8).

2. تفكيك مضمون «نريد التحويل إلى الويب»

عند تلقّي استشارة حول التحويل إلى الويب، أول ما نقوم به هو تفكيك الطلب. فخلف عبارة «نريد التحويل إلى الويب» يكمن عادةً واحد (أو أكثر) من الأسباب الثلاثة التالية.

(1) التخلص من عناء التوزيع والتحديث. المشكلة هي أنه «في كل مرة يصدر فيها إصدار جديد، يجب زيارة جميع الأجهزة لتثبيته». صحيح أن التحويل إلى الويب يحلّ هذه المشكلة، لكن يمكن حلّها أيضاً دون التحويل إلى الويب. فبالانتقال إلى طريقة توزيع تتضمّن آلية تحديث تلقائي مثل ClickOnce أو MSIX، يمكن تقليص أعمال التوزيع إلى ما يقارب الصفر مع بقاء التطبيق تطبيق Windows. للتفاصيل، راجع مقال «كيف تختار نموذج توزيع تطبيق Windows - MSI و MSIX و ClickOnce و xcopy والـ custom updaters». وإذا كان الدافع الوحيد هو عناء التوزيع، فإن التحويل إلى الويب استثمار مبالغ فيه.

(2) الرغبة في الاستخدام من أي مكان وأي جهاز. الاستخدام من عدة مواقع، والوصول من موقع العميل أو من المنزل، والاطّلاع عبر جهاز لوحي - هذا هو المجال الذي يتألق فيه التحويل إلى الويب حقاً. لكن حتى هنا، ينبغي التمييز بين الرغبة في «استخدام جميع الوظائف من أي مكان» والرغبة في «الاطّلاع على البيانات فقط من أي مكان». وفي الممارسة العملية، غالباً ما يكون المطلوب هو الحالة الثانية، وفي هذه الحالة يكفي اعتماد بنية تقسيم (الفصل 8) تضع أجزاء العرض والتجميع فقط على الويب.

(3) الرغبة في التخلّص من التقنية القديمة. الدافع هنا هو أمور مثل «الشخص الذي بنى التطبيق قد غادر الشركة» أو «القلق من البقاء على .NET Framework». هذا قلق مشروع، لكن الحل ليس بالضرورة التحويل إلى الويب. فإذا كنت ستعيد البناء على أي حال، وكانت طبيعة العمل تناسب سطح المكتب، فهناك خيار إعادة البناء كتطبيق Windows بأحدث إصدار من .NET (راجع «أيّها نختار من بين Windows Forms وWPF وWinUI - جدول قرار للتطوير الجديد، الأصول القائمة، التوزيع، والتعبير عن الـ UI»). كما ينبغي إدراك أن الانتقال إلى الويب لا يعني بالضرورة الهروب من التقادم التقني. فمن الأمثلة الحديثة نسبياً حالة نظام ويب داخلي بُني حصرياً لمتصفح IE، وفقد مكانه بعد إنهاء دعم IE (راجع «كيف نُطيل عمر أنظمة الويب الداخليّة المعتمدة على IE mode وكيف نخرج منها»). فتطبيقات الويب أيضاً تحتاج إلى صيانة لمواكبة تغيّرات أطر العمل والمتصفحات، و«التحويل إلى الويب» لا يعني «التحرر من الصيانة».

بهذا التفكيك، تتضح لنا: ما لا يُحلّ إلا بالتحويل إلى الويب، وما يمكن حلّه بطرق أخرى أيضاً، وما لا يُحلّ حتى مع التحويل إلى الويب. وبناءً على ذلك، ننتقل إلى التحقّق مما إذا كانت هناك وظائف تنطبق عليها «الحالات التي يُفضَّل فيها عدم التحويل إلى الويب» الموضّحة فيما يلي.

3. الحالة الأولى: الاتصال المباشر بالأجهزة والملحقات

التواصل مع معدّات التصنيع، واستيراد البيانات من أجهزة القياس والفحص، والموازين وقارئات الباركود المتصلة عبر منفذ تسلسلي (RS-232C)، والتحكّم الدقيق بطابعات خاصة - التطبيقات التي تتضمّن وظائف تتحدّث مباشرة مع الأجهزة (hardware) غير مناسبة بنيوياً لتحويل ذلك الجزء منها إلى الويب.

السبب بسيط: فالكود الذي يعمل في المتصفح يعمل داخل بيئة معزولة تُسمّى صندوق العزل (sandbox). فمن غير المقبول أن يتمكّن مجرد فتح صفحة ويب من العبث بملفات الجهاز أو أجهزته دون قيد، لذا يحجب المتصفح عمداً الوصول إلى الموارد المحلية. وهذا ليس عيباً في تقنية الويب، بل هو صلب التصميم الأمني نفسه. فحتى في Blazor WebAssembly، الذي يتيح كتابة عميل ويب بلغة C#، يعمل الكود داخل صندوق العزل الأمني الخاص بالمتصفح، ويؤدي الوصول إلى نظام الملفات أو فتح اتصال شبكي عشوائي إلى استثناء PlatformNotSupportedException1. وما يمكن فعله يبقى محصوراً في نطاق ما يدعمه المتصفح نفسه2.

قد يُعترض بالقول إن «Web Serial API أو WebUSB يتيحان التواصل التسلسلي من المتصفح». هذا صحيح، لكن دعم المتصفحات له محدود. فـ Web Serial API مدعومة في متصفحات Chromium مثل Chrome وEdge، وأضافت نسخة سطح المكتب من Firefox الدعم أيضاً ابتداءً من Firefox 151 الصادر في مايو 2026، لكن Safari لا يزال غير مدعوم (وعلى الأجهزة المحمولة، يقتصر الدعم على دعم جزئي في Chrome لأندرويد للتواصل التسلسلي عبر Bluetooth)، أما WebUSB فلا تزال مقصورة على متصفحات Chromium حتى الآن3. وإلى جانب هذا القيد الذي يمسّ أكبر ميزة للتحويل إلى الويب - وهي «إمكانية الاستخدام من أي متصفح» - فإن الاتصال بالجهاز يتطلّب عادةً (على الأقل في المرة الأولى أو عند إضافة جهاز جديد) أن يختار المستخدم الجهاز ويمنح الإذن يدوياً عبر مربع حوار في المتصفح، ما يجعل هذا الخيار في كثير من الأحيان غير مجدٍ كوسيلة للتكامل مع الأجهزة في أنظمة الأعمال.

هناك أيضاً حل بديل يتمثّل في بنية «تطبيق ويب + عميل تكامل مقيم (agent) على كل جهاز»، لكن هذه بنية يبقى فيها في النهاية برنامج Windows يحتاج إلى توزيع وتحديث. وهذا في حد ذاته ليس أمراً سيئاً - بل هو في الواقع أحد أشكال بنية التقسيم التي سنتناولها في الفصل 8 - لكن يجب توضيح ذلك في مرحلة التخطيط، لأنه مختلف تماماً عن التوقّع الأولي بأن «التحويل إلى الويب سيُغني عن تثبيت أي شيء على الأجهزة».

لمزيد من التفاصيل حول تصميم جزء التكامل مع الأجهزة، راجع أيضاً «أفضل الممارسات للتحقّق من حالة الأجهزة الخارجيّة وعرضها».

4. الحالة الثانية: التكامل العميق مع الملفات المحلية أو التطبيقات الأخرى

الحالة الشائعة التالية هي التطبيقات التي يكون فيها التكامل مع الملفات الموجودة على الجهاز أو مع تطبيقات أخرى هو جوهر العمل.

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

المبدأ الأساسي هو أن وصول المتصفح إلى الملفات يقتصر على «الملف الذي يختاره المستخدم في كل مرة عبر مربع حوار». فلا يمكن الوصول الجماعي دون تدخّل المستخدم، ولا يمكن إجراء مراقبة مقيمة تستمر في العمل حتى مع إغلاق المتصفح. صحيح أن واجهة File System Access API الحديثة تتيح الوصول على مستوى مجلد يختاره المستخدم، بل وظهرت واجهة تجريبية (FileSystemObserver) لمراقبة التغييرات داخل مجلد مختار طوال فترة فتح الصفحة، لكن هذه الواجهات مقصورة على متصفحات Chromium4، وتحمل المشكلة نفسها المتعلقة بـ«تقييد المتصفحات المدعومة» التي رأيناها في التكامل مع الأجهزة. أما تشغيل عملية محلية أخرى (مثل Excel) والتحكّم بها من المتصفح، فهو أمر غير ممكن أصلاً.

محاولة تحويل هذا النوع من الوظائف إلى الويب تتطلّب تغيير سير العمل إلى نمط «يرفع المستخدم الملفات إلى الخادم، وتُعالَج على جانب الخادم». وإذا كان العمل يمكن أن يسير بهذه الطريقة، فهذا خيار مقبول، لكن إن كانت هناك اعتبارات مثل التعامل يومياً مع ملفات بحجم جيجابايت، أو معالجة بيانات لا يمكن إخراجها خارج الشركة محلياً وبشكل كامل، أو الارتباط الوثيق بأصول Excel، فمن الأنسب - لكل من المطوّر والمستخدم - الإبقاء على ذلك الجزء كتطبيق Windows (أو كخدمة Windows إذا كانت المعالجة غير مأهولة، مثل مراقبة المجلدات أو المعالجة الدفعية). لكن يجب الانتباه بشكل خاص إلى مكان وضع التكامل مع Excel عبر COM: فمايكروسوفت لا توصي بأتمتة Office من بيئات غير مأهولة وغير تفاعلية مثل الخدمات (services)، ولا تدعم ذلك رسمياً5، لذا ينبغي وضع العمليات التي تُشغّل Excel تلقائياً على جانب تطبيق سطح المكتب الذي يستخدمه مستخدم مسجّل دخوله، أو استبدالها بقراءة وكتابة عبر مكتبة من نوع Open XML لا تُشغّل Office إطلاقاً. تناولنا طريقة بناء التكامل مع Excel في مقال «كيف تبني إخراج تقارير Excel - دليل قرار عمليّ بين COM Automation وOpen XML والمقاربة المعتمدة على القوالب والمقايضات»، كما تناولنا مراقبة المجلدات في «كيفيّة استخدام FileSystemWatcher بأمان - الأحداث المفقودة والإشعارات المكرّرة وفخاخ كشف الاكتمال».

5. الحالة الثالثة: الاستخدام في مواقع ذات شبكة غير مستقرة لمهام لا يمكن أن تتوقف

تفترض تطبيقات الويب، بحكم بنيتها، أن الاتصال بالشبكة قائم دائماً. وهذا ينطبق بالطبع على تطبيقات الويب المعتمدة على العرض من جانب الخادم (server-side rendering)، وكذلك على Blazor Server الشائع في عالم C#، حيث تُعالَج جميع تفاعلات الواجهة عبر اتصال دائم بالخادم، ما يعني أن التطبيق يتوقف عن العمل فور انقطاع الاتصال. وتنص الوثائق الرسمية صراحةً على عدم وجود دعم للعمل دون اتصال2.

يصبح هذا مشكلة في بيئات مثل التالية:

  • المصانع والمستودعات والمواقع الخارجية: حيث تُحجب إشارة Wi-Fi بسبب الرفوف المعدنية أو الآلات، وتحدث انقطاعات لحظية بشكل يومي
  • خطوط الإنتاج التي لا يمكن أن تتوقف: حيث يؤثّر توقّف شاشة التسجيل أو التوجيه لبضع دقائق فقط على الإنتاج أو الشحن
  • المواقع ذات الاتصال الضعيف أو غير المستقر: كالمكاتب المؤقتة التي تعتمد على شبكات الجوال، أو على متن السفن، أو في المناطق الجبلية

يمكن بسهولة بناء تطبيق Windows أصلي (native) يحتفظ بالبيانات محلياً، ويواصل العمل حتى دون اتصال، ثم يُزامن البيانات بعد استعادة الاتصال. بل إن العمل دون اتصال هو أحد الأسباب التي تذكرها مايكروسوفت نفسها لاختيار التطبيقات الأصلية6. صحيح أنه من الممكن تقنياً جعل تطبيق ويب يعمل دون اتصال باستخدام PWA (عبر Service Worker) أو بتصميم يحتفظ بالبيانات على جانب العميل، لكن بناء ذلك بالكامل - بما يشمل المزامنة وحل التعارضات - يتطلّب استثماراً إضافياً كبيراً، وهو ما يعمل في الاتجاه المعاكس للتوقّع الأولي بأن «التحويل إلى الويب سيُقلّل التكلفة».

معيار الحكم هنا هو: «إذا انقطعت الشبكة لمدة 30 دقيقة، فهل يمكن لهذا العمل أن ينتظر؟». وإذا كانت الإجابة لا، فينبغي على الأقل أن تكون الشاشة المسؤولة عن ذلك العمل تعمل محلياً.

6. الحالة الرابعة: الإدخال السريع والكبير عبر لوحة المفاتيح كجوهر للعمل

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

  • تأخّر الاستجابة: في النماذج المعتمدة على اتصال دائم بالخادم مثل Blazor Server، تمرّ كل تفاعلة من المستخدم عبر رحلة ذهاب وإياب عبر الشبكة، ما يرفع من زمن استجابة الواجهة2. وحتى لو كان التأخير بضع عشرات من المللي ثانية لكل عملية، فإنه يُشعَر به بوضوح كـ«إحساس بالتعثّر» في أعمال إدخال تتضمّن آلاف العمليات يومياً.
  • إعادة إنتاج تفاعلات لوحة المفاتيح: أمور تُعدّ من «بديهيات أعمال الإدخال» مثل الانتقال بين الحقول بمفتاح Enter، وتخصيص مفاتيح الوظائف (function keys)، والتحقّق الفوري من صحة البيانات أثناء الكتابة - يجب بناؤها مع الاصطدام بالسلوك الافتراضي للمتصفح (مثل إرسال النموذج عند الضغط على Enter، أو فتح المساعدة عند الضغط على F1). الأمر ليس مستحيلاً، لكنه يعني دفع تكلفة إضافية للحاق بمستوى الجودة الذي يوفّره إطار عمل سطح المكتب ومكوّنات الشبكة (grid) منذ البداية.
  • شبكات البيانات الكبيرة (grids): لتحقيق شبكة بيانات بجودة سطح المكتب على الويب - تعرض عشرات الآلاف من الصفوف بسلاسة عبر التمرير الافتراضي (virtual scroll)، وتدعم تحرير الخلايا وتثبيت الأعمدة والنسخ واللصق - يلزم اعتماد مكوّن تجاري غني بالميزات وضبط دقيق يتناسب معه.

بالنسبة للعرض أو الموافقة أو التسجيل العرضي، تكفي نماذج الويب. لكن بالنسبة للشاشات التي ترتبط فيها سرعة الإدخال ذاتها مباشرةً بإنتاجية العمل، تحقّق بهدوء مما إذا كانت ستستفيد فعلاً من ميزة التحويل إلى الويب (إمكانية الاستخدام من أي مكان) - أم أن تلك الشاشة، في نهاية المطاف، لن تُستخدم إلا من مقعد ثابت في المكتب. فإذا كان مكان الاستخدام ثابتاً، فلن يجني التحويل إلى الويب أي فائدة، بل سيكون هناك خسارة فقط.

7. الحالة الخامسة: البدء بـ«إعادة البناء» بتقدير تكلفة «النقل»

تناولنا حتى الآن الوظائف وأنماط الاستخدام، أما النقطة الأخيرة فتتعلّق ببنية التكلفة. النمط النموذجي الذي يجعل خطة التحويل إلى الويب تنهار في منتصف الطريق هو إجراء التقدير على أساس تصوّر «نقل» - أي «نقل ما هو موجود حالياً إلى الويب» - ثم اكتشاف لاحقاً أن الأمر كان في الواقع إعادة بناء كاملة.

  • لا يمكن نقل أصول الشاشات كما هي. لا توجد وسيلة عملية لتحويل تعريفات ومنطق شاشات WinForms أو WPF تلقائياً إلى الويب، بل يجب إعادة تصميم جميع الشاشات وبناء واجهتها من جديد. وبذلك يصبح ناتج ضرب عدد الشاشات في مستوى تعقيدها هو حجم العمل مباشرةً.
  • يجب أولاً جرد منطق الأعمال بالكامل. ليس من غير المألوف في تطبيق يعمل منذ سنوات طويلة أن توجد قواعد عمل غير مذكورة في المواصفات إلا داخل الكود نفسه. ويتضمّن التحويل إلى الويب استخراج كل ذلك وإعادة تنفيذه. وينطبق هنا تماماً مبدأ «عدم الشروع في إعادة كتابة كاملة فجأة» الذي تناولناه في مقال نقل تطبيقات VB6 / Access.
  • تكاليف التشغيل بعد الإنجاز تزداد بنيوياً. كانت صيانة تطبيق سطح المكتب تعني الاعتناء بالأجهزة الطرفية، لكن مع تطبيق الويب تنشأ أعمال مستمرة تتمثّل في بناء الخادم (أو البنية السحابية) ومراقبته والنسخ الاحتياطي وتحديث الشهادات والأمان. وإن لم يتوفر هذا النظام داخل الشركة، فستكون هناك تكلفة شهرية للاستعانة بجهة خارجية. لذا يجب أن تشمل مقارنة تكلفة التحويل إلى الويب هذه التكلفة التشغيلية المستمرة، لا تكلفة التطوير الأولية فقط.
  • تتغيّر افتراضات الأمان. فبمجرد تحويل تطبيق كان يعمل فقط داخل الشبكة المحلية للشركة إلى الويب والسماح بالوصول إليه من خارجها، يرتفع مستوى المتطلبات المطلوبة في المصادقة والتفويض وتشفير الاتصال والحماية من الهجمات درجة كاملة. وهذا أيضاً جزء من «تكلفة التحويل إلى الويب».

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

8. الحل الواقعي: تجاوز الخيار الثنائي بين الويب الكامل أو Windows الكامل

عند تطبيق كل ما سبق على أرض الواقع، تكون الإجابة في معظم الحالات ليست «التحويل الكامل إلى الويب» ولا «الإبقاء على الوضع الحالي»، بل التقسيم.

الفكرة بسيطة: تطبيق جدول القرار من الفصل 1 لا على التطبيق ككل، بل على كل وظيفة على حدة.

  • ما يوضع على الويب: عرض البيانات والبحث فيها وتجميعها للبيانات التي يريد الاطّلاع عليها عدة أشخاص من عدة مواقع، وتنزيل التقارير، والعمليات الخفيفة كالموافقات. وتندرج صيانة البيانات الرئيسية (master data) هنا في الغالب أيضاً.
  • ما يبقى على Windows: التكامل مع الأجهزة والملحقات، ومراقبة الملفات المحلية ومعالجتها الدفعية، والعمل الميداني الذي لا يمكن أن يتوقف حتى دون اتصال، وشاشات الإدخال السريع.
  • ما يُشترك فيه: قاعدة البيانات ومنطق الأعمال. يتم توحيد البيانات بحيث يرجع كل من تطبيق الويب وتطبيق Windows إلى نفس واجهة برمجة التطبيقات (أو قاعدة البيانات). وبتوحيد هذا الجزء، تتحقق بنية تُلبّي معظم دوافع التحويل إلى الويب: «يُدخل الميدان البيانات عبر تطبيق Windows، ويطّلع المقر الرئيسي عليها فوراً عبر المتصفح».

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

وتجدر الإشارة إلى أنه بالنسبة لمتطلبات مثل «الرغبة في بناء الواجهة بتقنيات الويب مع الحاجة إلى الوصول إلى الموارد المحلية أيضاً»، هناك أيضاً خيار الأنماط الهجينة مثل Electron أو Blazor Hybrid (باستخدام WebView2). فهي تتيح استخدام واجهة مبنية بتقنيات الويب دون التقيّد بقيود صندوق عزل المتصفح، لكن يجب الانتباه إلى أنها تظل تطبيق سطح مكتب يحتاج إلى توزيع، ولا تُجيب على طلب «الرغبة في الاستخدام من خلال المتصفح فقط».

9. قائمة تحقّق قبل اتخاذ قرار التحويل إلى الويب

التحقّق مما يلي قبل طلب عرض سعر أو تقديم موافقة داخلية يقلّل من احتمال إعادة العمل.

  1. تفكيك الدافع: ما هي المشكلة الحقيقية - عناء التوزيع، أم مكان الاستخدام، أم التقادم التقني؟ إذا كانت المشكلة هي التوزيع فقط، فهل يكفي تغيير طريقة التوزيع؟
  2. وجود تكامل مع الأجهزة: هل توجد وظائف تتواصل مباشرة مع أجهزة serial أو USB أو أجهزة قياس أو طابعات خاصة؟ إذا كان الأمر كذلك، فحدّد أولاً كيفية التعامل مع ذلك الجزء (الإبقاء عليه على Windows / اعتماد بنية عميل agent).
  3. الاعتماد على الموارد المحلية: هل توجد مراقبة للمجلدات، أو معالجة دفعية للملفات، أو تكامل بين العمليات مع Excel وما شابه؟ وهل يمكن تغيير سير العمل إلى نمط معالجة عبر الخادم؟
  4. متطلبات العمل دون اتصال: إذا انقطعت الشبكة لمدة 30 دقيقة، فهل يمكن لهذا العمل أن ينتظر؟
  5. وزن أعمال الإدخال: هل توجد شاشات يُكتب فيها طوال اليوم عبر لوحة المفاتيح؟ وهل تُستخدم تلك الشاشة فعلاً «من أي مكان»؟
  6. واقع المستخدمين والأماكن: من الذي يريد رؤية أو إدخال ماذا، ومن أين؟ هل الأمر هو «الجميع يحتاجون كل الوظائف من خارج الشركة»، أم مجرّد «المقر الرئيسي يريد الاطّلاع على البيانات فقط»؟
  7. نظام التشغيل: من الذي سيتولى بناء الخادم ومراقبته وتحديث أمانه؟ وكم ستبلغ تكلفة ذلك شهرياً؟
  8. مكان وجود منطق الأعمال: هل تتطابق المواصفات مع الكود؟ وهل تم تضمين الفترة الزمنية اللازمة للجرد في التقدير؟

إذا انطبق أي بند من البنود 2 إلى 5، نوصي بالتفكير في بنية التقسيم كنهج أساسي بدلاً من التحويل الكامل إلى الويب. للاطّلاع على الاعتبارات العامة التي ينبغي تنظيمها قبل طلب التطوير، راجع أيضاً «أمور ينبغي تنظيمها قبل طلب تطوير تطبيق Windows بالتعاقد الخارجي».

الخلاصة

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

لهذا السبب بالتحديد، فإن القرار العملي ليس «التحويل إلى الويب أم لا»، بل يصبح مسألة تصميم: «أي الوظائف يوضع على الويب، وأيها يبقى على Windows، وما الذي يُشترك فيه؟». ومن جرد التطبيق الحالي إلى تقييم جدوى التحويل إلى الويب وتصميم بنية التقسيم، غالباً ما يتطلّب الأمر حكماً مبنياً على الاطّلاع الفعلي على الكود وواقع التشغيل، فإن كنتم في حيرة، لا تترددوا في التواصل معنا.

مقالات ذات صلة

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت المحدودة مع استشارات تقنية حول تقييم جدوى تحويل تطبيقات Windows الحالية إلى الويب، وتصميم بنية تقسيم بين الويب وWindows، وتطوير أو تعديل تطبيقات الأعمال التي تتضمّن تكاملاً مع الأجهزة ومعالجة محلية.

المراجع

  1. Microsoft Learn، نماذج استضافة تطبيقات Blazor (Blazor لمطوّري ASP.NET Web Forms). حول تنفيذ تجميعات (assemblies) Blazor WebAssembly داخل صندوق العزل الأمني الخاص بالمتصفح، وإطلاق استثناء PlatformNotSupportedException عند محاولة الوصول إلى نظام الملفات أو فتح اتصال شبكي عشوائي. ↩ ↩2 ↩3

  2. Microsoft Learn، نماذج استضافة Blazor في ASP.NET Core. حول كون Blazor WebAssembly محدوداً بنطاق ما يدعمه المتصفح، وكون Blazor Server يستلزم رحلة ذهاب وإياب عبر الشبكة لكل تفاعلة من المستخدم ما يرفع من زمن استجابة الواجهة، وتوقّف التطبيق عن العمل عند انقطاع الاتصال مع عدم وجود دعم للعمل دون اتصال. ↩ ↩2 ↩3 ↩4

  3. MDN Web Docs، Web Serial API وUSB (WebUSB API). حول اقتصار دعم Web Serial API على متصفحات Chromium (مثل Chrome وEdge) ونسخة سطح المكتب من Firefox (من الإصدار 151 فصاعداً)، وعدم دعم Safari، واقتصار الدعم في Chrome لأندرويد (138 فصاعداً) على دعم جزئي للتواصل التسلسلي عبر Bluetooth RFCOMM، واقتصار WebUSB على متصفحات Chromium (انظر قسم Browser compatibility في كل صفحة). ↩

  4. MDN Web Docs، File System API وFileSystemObserver. حول اقتصار دعم الإضافات مثل showOpenFilePicker / showDirectoryPicker للوصول إلى الملفات والمجلدات المحلية، وواجهة FileSystemObserver (تجريبية وقبل التوحيد القياسي) لمراقبة تغييرات مجلد يختاره المستخدم، على متصفحات Chromium، وعدم توفّرها في Firefox أو Safari. ↩

  5. Microsoft Learn، اعتبارات الأتمتة غير المأهولة لـ Office وMicrosoft Support، اعتبارات أتمتة Office من جانب الخادم. حول عدم توصية مايكروسوفت وعدم دعمها لأتمتة تطبيقات Office من عملاء غير مأهولين وغير تفاعليين (مثل ASP.NET وDCOM وخدمات NT) بسبب مخاطر عدم الاستقرار والتعليق (deadlock)، وتوجيهها نحو بدائل مثل التحرير المباشر لتنسيقات ملفات Open XML. ↩

  6. Microsoft Learn، الأسئلة الشائعة حول تطوير تطبيقات Windows. حول ذكر الأداء، والتكامل العميق مع واجهات برمجة تطبيقات Windows، ودعم العمل دون اتصال، كأسباب لاختيار إطار عمل أصلي (WinUI / WPF / WinForms) لتطبيق مخصّص لـ Windows فقط. ↩

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

طريقة التفكير في تصميم UX لتطبيقات Windows - جدول قرار لتحديد ما يُعطى الأولوية في ToC / ToB / المراقبة / الأجهزة الميدانية / الأدوات المقيمة

يُنظّم هذا المقال أولويّات UX لتطبيقات Windows في صورة جدول قرار حسب ToC وToB والمراقبة وأجهزة الميدان، ليختار القارئ الكثافة والملاحة وأ...

قراءة المقالة

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

إذا كنا سنحدّث تطبيق Windows قديماً، فهل من الأفضل تحويله إلى الويب في نفس الوقت؟
لا نُنصح بتحويل التطبيق إلى الويب لمجرد أنه «قديم». فالتحويل إلى الويب يتطلب جهداً أقرب إلى إعادة البناء الكاملة منه إلى مجرد النقل، كما أن تطبيقات الويب نفسها معرّضة للتقادم التقني (ومن الأمثلة النموذجية على ذلك أنظمة الويب الداخلية التي بقيت مرتبطة حصرياً بمتصفح IE). لذا يجب أن يكون معيار القرار هو طريقة استخدام التطبيق، لا قِدَم التقنية أو حداثتها. فإذا كان التطبيق يُستخدم من عدة مواقع وتريد تقليل إدارة الأجهزة، فإن التحويل إلى الويب يحقق فائدة واضحة. أما إذا كان جوهر التطبيق هو التكامل مع الأجهزة أو معالجة الملفات المحلية، فغالباً ما يكون تحديثه مع إبقائه تطبيق Windows - كالانتقال إلى إصدار أحدث من .NET أو إعادة تصميم الواجهة - هو الخيار الأفضل من حيث الجدوى الاقتصادية.
ألا يُلغي التحويل إلى الويب عناء التوزيع والتثبيت على الأقل؟
صحيح أن التحويل إلى الويب يُلغي أعمال التوزيع على جانب العميل، لكن إذا كان الدافع الوحيد هو «التخلص من عناء التوزيع»، فهناك حلول أخف من التحويل الكامل إلى الويب. فبالتحوّل إلى طريقة توزيع تتضمّن آلية تحديث تلقائي مثل ClickOnce أو MSIX، يمكن إلغاء الحاجة إلى زيارة كل جهاز لتثبيت التحديث تقريباً، مع بقاء التطبيق تطبيق Windows. وفي المقابل، فإن التحويل إلى الويب يستبدل هذه التكلفة بتكلفة تشغيلية مستمرة جديدة، تتمثل في بناء الخادم (أو البنية السحابية) ومراقبته وتحديث أمانه باستمرار. لذا يجب النظر في كلا الجانبين - التكلفة التي ستزول والتكلفة التي ستُضاف - قبل اتخاذ القرار.
هل يمكن تحويل جزء فقط من التطبيق إلى الويب؟
نعم، بل إن هذا هو الحل الواقعي الأكثر شيوعاً في الممارسة العملية. النمط النموذجي هو وضع عرض البيانات وتجميعها والتقارير والوصول إليها من عدة مواقع على الويب، مع الإبقاء على التكامل مع الأجهزة والإدخال السريع في الميدان ومعالجة الملفات المحلية كتطبيق Windows، ثم ربط الجزأين عبر واجهة برمجة تطبيقات (API) وقاعدة بيانات مشتركتين. مقارنةً بالتحويل الكامل إلى الويب، يكون نطاق إعادة البناء دفعة واحدة أصغر، ويمكن التقدّم تدريجياً بدءاً من الأجزاء التي تحقق أكبر فائدة من التحويل إلى الويب.
ماذا عن الخيارات الوسيطة مثل Electron أو PWA أو Blazor Hybrid؟
يجب التمييز بين هذه الخيارات لأنها مختلفة الطبيعة. يعمل كل من Electron وBlazor Hybrid (باستخدام WebView2) كتطبيقات سطح مكتب، لذا يمكنها الوصول إلى الملفات والأجهزة دون التقيّد بقيود صندوق العزل (sandbox) الخاص بالمتصفح، مع كتابة الواجهة بتقنيات الويب. لكنها تظل، رغم ذلك، تطبيقات سطح مكتب تحتاج إلى توزيع وتحديث، ولا تُجيب على طلب «جعل التطبيق يعمل من خلال المتصفح فقط». أما PWA، فحتى لو بدت وكأنها مثبَّتة - كأن تُثبَّت على شريط المهام مثلاً - فهي في جوهرها تبقى تطبيق ويب يعمل داخل المتصفح، وتخضع لنفس قيود الوصول إلى الموارد المحلية التي يخضع لها أي تطبيق ويب عادي. لذلك من المهم أولاً تحديد المشكلة الفعلية التي تسعى لحلّها من خلال التحويل إلى الويب.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.

تواصل معنا

روابط عامة

GitHub LinkedIn X COM_BLAS COM_BigDecimal
العودة إلى المدونة