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

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

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

سجل التعديلات (2 تحديثات، آخر تحديث 2 Sep، 2026)

سجل بالتغييرات التي أُجريت على هذا المقال. وحيثما حُفظت نسخة سابقة، تبقى متاحة للقراءة عبر رابط دائم يحمل معرّف DOI.

أُعيدَت الترجمة العربية كترجمة كاملة عن النص الياباني الأصلي، وأُضيفَت خريطة المعرفة.
أعيدت الترجمة كترجمة كاملة عن النص الياباني الأصلي. كانت النسخة العربية السابقة مختصراً يسقط أبواباً وجداول ورسوم Mermaid وتعليقات الأشكال وFAQ. أُعيدت هذه العناصر وفق الأصل الياباني، والادّعاءات التقنية مطابقة للنسخة اليابانية.
النشر الأول
الاستشهاد بهذا المقال(DOI: 10.5281/zenodo.21621680)

هذا المقال محفوظ على Zenodo. يرد أدناه معرّف DOI الذي يشير دائمًا إلى أحدث نسخة، ومعرّف DOI المثبَّت على النسخة التي تقرؤها.

غو كومورا (2026). متى لا يُفضَّل تحويل تطبيق Windows إلى الويب: جدول القرار وحل «التقسيم» الواقعي. شركة كومورا سوفت ذ.م.م.. https://doi.org/10.5281/zenodo.21621680 https://comcomponent.com/ar/blog/windows-app-web-migration-decision/

DOI (أحدث نسخة)
10.5281/zenodo.21621680
DOI (هذه النسخة)
10.5281/zenodo.22241029

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

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

1. الخلاصة أولاً (جدول القرار)

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

الرموز تعني ما يلي. ◎ = أثر التحويل إلى الويب كبير / ○ = مناسب للتحويل إلى الويب / △ = يستدعي الحذر (قد لا يناسب بحسب الشروط. انظر أولاً إلى حلول غير التحويل إلى الويب) / × = غير مناسب (القيد بنيوي في المتصفح، ويصعب قلبه بالبناء الإضافي).

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

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

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

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 21، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

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

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

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

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

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

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

لاحظ أن الحالات التالية تنقسم إلى نوعين. الحالات 1 إلى 4 (الفصول 3 إلى 6) حديث عن «عدم الملاءمة التقنية للتحويل إلى الويب»، والحالة 5 (الفصل 7) حديث عن «سوء قراءة بنية التكلفة». الأولى إن انطبقت تقود مباشرة إلى عدم إخراج تلك الوظيفة إلى الويب. أما الثانية فحتى إن انطبقت ليست سبباً للإيقاف، بل لتصحيح افتراضات التقدير.

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

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

السبب بسيط: الكود الذي يعمل في المتصفح يعمل داخل بيئة معزولة تُسمّى صندوق العزل (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. وإلى جانب هذا القيد الذي يمسّ أكبر ميزة للتحويل إلى الويب — «الاستخدام من أي متصفح» — فإن الاتصال بالجهاز يتطلّب عادةً (على الأقل في المرة الأولى أو عند إضافة جهاز) أن يختار المستخدم الجهاز ويمنح الإذن عبر مربع حوار في المتصفح، ما يجعل هذا الخيار في كثير من الأحيان غير مجدٍ كوسيلة تكامل مع الأجهزة في أنظمة الأعمال.

دعم المتصفحات المذكور هنا معلومة سريعة التغيّر وقصيرة العمر (ودعم Firefox لـ Web Serial API حركة حديثة نسبياً). عند الحكم الفعلي لا تستخدم وصف هذه المقالة كما هو، بل راجع أحدث حالة في قسم «Browser compatibility» في صفحات MDN لكل API. أما مبدأ أن «صندوق العزل يقيّد الوصول إلى الموارد المحلية» فهو فلسفة تصميم، وهذا لا يتغيّر في الأمد القصير.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

عند استخدامها في الموافقات الداخلية أو المقارنة داخل الشركة، يسهل النقاش إذا وُحِّدت على الشكل التالي.

الإجمالي = تكلفة التطوير الأولية (جهد إعادة البناء) + التكلفة الشهرية للتشغيل × 12 × سنوات الاستخدام المتوقعة + تكاليف انتقالية لمرة واحدة (ترحيل البيانات، التدريب، فترة التشغيل المتوازي)

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

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

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

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

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

يُبقى على Windows ── تطبيق كل جهازيُخرَج إلى الويب ── المتصفحالتكامل مع الأجهزة والملحقاتمراقبة الملفات المحلية والمعالجة الدفعيةالعمل دون اتصال والإدخال السريعالعرض والبحث والتجميعتنزيل التقارير والموافقةصيانة البيانات الرئيسيةمنطق الأعمال المشترك وAPIقاعدة البيانات

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

  • ما يوضع على الويب: عرض البيانات والبحث فيها وتجميعها للبيانات التي يريد الاطّلاع عليها عدة أشخاص من عدة مواقع، وتنزيل التقارير، والعمليات الخفيفة كالموافقات. وتندرج صيانة البيانات الرئيسية هنا في الغالب أيضاً.
  • ما يبقى على Windows: التكامل مع الأجهزة والملحقات، ومراقبة الملفات المحلية ومعالجتها الدفعية، والعمل الميداني الذي لا يمكن أن يتوقف حتى دون اتصال، وشاشات الإدخال السريع.
  • ما يُشترك فيه: قاعدة البيانات ومنطق الأعمال. تُوحَّد البيانات بحيث يرجع كل من تطبيق الويب وتطبيق Windows إلى نفس API (أو قاعدة البيانات). وبتوحيد هذا الجزء تتحقق بنية تلبّي معظم دوافع التحويل إلى الويب: «يُدخل الميدان عبر تطبيق 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 app hosting models (Blazor for ASP.NET Web Forms developers). حول تنفيذ تجميعات Blazor WebAssembly داخل صندوق العزل الأمني للمتصفح، وإطلاق استثناء PlatformNotSupportedException عند محاولة الوصول إلى نظام الملفات أو فتح اتصال شبكي عشوائي. ↩ ↩2 ↩3

  2. Microsoft Learn، ASP.NET Core Blazor hosting models. حول كون 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، Considerations for unattended automation of Office وMicrosoft Support، Considerations for server-side Automation of Office. حول عدم توصية Microsoft وعدم دعمها لأتمتة تطبيقات Office من عملاء غير مأهولين وغير تفاعليين (مثل ASP.NET وDCOM وخدمات NT) بسبب مخاطر عدم الاستقرار والتعليق (deadlock)، وتوجيهها نحو بدائل مثل التحرير المباشر لتنسيقات ملفات Open XML. ↩

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

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

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

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

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

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

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

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

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

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

غو كومورا

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

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

تواصل معنا
العودة إلى المدونة