باستخدام VCL للويب (intraweb) كخدعة لإضافة واجهة ويب إلى تطبيق Delphi Win32 LEGACY غير مستقر (2 مستويات) ، هل يكون من المنطقي؟

Question

يحافظ فريقي على تطبيق WIN32 Delphi لخادم العميل الضخم. إنه تطبيق عميل/خادم (عميل سميك) يستخدم مكونات Devart (SDAC) للاتصال بخادم SQL.

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

الآن هناك طلب من واجهة ويب ، لدي العديد من الخيارات بالطبع ، في هذا السؤال أريد التركيز على VCL لخيار الويب (intraweb).

تتمثل الفكرة في استخدام الكود الشائع (نفس ملفات PAS) لكل من تطبيق العميل/الخادم وتطبيق الويب. سمعت عن العديد من الأشخاص الذين نقلوا التطبيقات القديمة من دلفي إلى intraweb ، لكنني هنا أحاول الحفاظ على العميل الكثيف أيضًا.

الفكرة هي استخدام التعليمات البرمجية المشتركة ، قد تكون مع بعض توجيهات البرمجيات لكتابة رمز محدد:

{$IFDEF CLIENTSERVER}
  {here goes the thick client specific code}
{$ELSE}
  {here goes the Intraweb specific code}
{$ENDIF}

ثم هناك مشكلة أخرى وهي "خطة الترحيل" ، دعنا نقول أن لدي 300 ميزة ، وفي الإصدار الأول ، سيكون لدي 50 منها متوفرة فقط في تطبيق الويب. كيف تتتبع ذلك؟ كنت أفكر في (AB) باستخدام واجهات Delphi للتعامل مع هذا. على سبيل المثال لمصادقة المستخدم ، يمكنني نقل جميع الكود ذي الصلة في الإجراء وإعلان واجهة مثل:

type
  IUserAuthentication= interface['{0D57624C-CDDE-458B-A36C-436AE465B477}']
    procedure UserAuthentication;
  end;

وبهذه الطريقة أثناء تنفيذ واجهة iuserauthentication في كلا التطبيقين (العميل الكثيف والغلق) ، أعلم أن هذه الميزة "تم نقلها" على الويب. على أي حال ، لا أعرف ما إذا كان هذا النهج منطقيًا. لقد صنعت نموذجًا أوليًا لمحاكاة العملية برمتها. إنه يعمل لتطبيق "Hello World" ، لكنني أتساءل عما إذا كان من المنطقي على تطبيق كبير أو فكرة الواجهة هذه غير منتجة فقط ويمكن أن تأتي بنتائج عكسية.

سؤالي هو: هل هذا النهج منطقي؟ (فكرة الواجهة هي مجرد فكرة إضافية ، فهي ليست مهمة للغاية لأن جزء الكود الشائع الموضح أعلاه) هل هو خيار قابل للتطبيق؟

أنا أفهم أن هذا يعتمد على الكثير من نوع التطبيق ، على أي حال أن أكون عامًا في مجال CRM/المحاسبة ، وعادة ما يكون عدد المستخدمين المتزامنين على تثبيت واحد أقل من 20 مع قمم 50.

تعليق إضافي (تحديث): أطرح هذا السؤال لأنه بما أنني لا أملك تطبيق N-tier ، فأنا أراه intraweb كخيار فريد للحصول على تطبيق ويب يحتوي على رمز مشترك مع العميل الكثيف. إن تطوير خدمات الويب من رمز Delphi لا معنى له في حالتي المحددة ، وبالتالي فإن البديل الذي لدي هو كتابة واجهة الويب باستخدام ASP.NET (تكرار منطق العمل) ، لكن في هذه الحالة لا يمكنني الاستفادة من الرمز المشترك في طريقة سهلة. نعم ، ربما يمكنني استخدام DLLS ، لكن الكود الخاص بي غير مناسب لذلك.

Answer 1

أهم شيء عليك أن تتذكره هو:

• يتم استخدام عملية العميل السميك .exe من قبل شخص واحد في وقت واحد (سيكون لدى العديد من الأشخاص مثيلات متعددة من ذلك .exe).
• سيتم استخدام عملية intraweb .exe الخاصة بك من قبل العديد من الأشخاص في وقت واحد. انهم جميعا يشتركون في نفس مثيل العملية.

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

يبدأ هذا بمنطق العمل الذي يتحدث إلى قاعدة البيانات: يجب أن تكون قادرًا على امتلاك اتصالات قاعدة بيانات متعددة في نفس الوقت (في الممارسة العملية ، تعمل مجموعة من اتصالات قاعدة البيانات بشكل أفضل).

في تجربتي ، عندما يمكنك إعادة صياغة منطق عملك إلى Datamodules ، يكون لديك نقطة انطلاق جيدة لدعم كل من intraweb ونسخة عميل سميك من تطبيقك.

يجب ألا تنسى واجهة المستخدم:

• يدعم العملاء السميكون أشكال الوسائط ، ولديهم واجهة مستخدم أكثر ثراءً
• تدعم متصفحات الويب مربعات الحوار فقط (ثم: هذه محدودة للغاية) ، كل ما يكلفه توسيط واجهة المستخدم الكثير من وقت التطوير (على سبيل المثال ، لدى TMS بعض مكونات جميلة لل intraweb)

بعد ذلك ، لتتصدر ذلك ، عليك التعامل مع الطبيعة عديمة الجنسية لبروتوكول HTTP. للتغلب على هذا ، تحتاج إلى جلسات. سوف يعتني intraweb بمعظم جزء الجلسة.
لكن عليك أن تسأل نفسك أسئلة مثل هذه:

• ماذا يجب أن يحدث إذا كان المستخدم في وضع الخمول لمدة xx؟
• ما مقدار حالة الجلسة التي يمكنني تخزينها في الذاكرة؟ وماذا لو لم يكن مناسبا؟
• ماذا أفعل مع حالة الجلسة التي لا تتناسب مع الذاكرة؟

هذه مجرد بداية ، لذلك دعنا تعرف عندما تحتاج إلى مزيد من المعلومات.
إذا أصبح الأمر محددًا جدًا لتطبيقك ، فيمكنك الاتصال بي مباشرة: فقط Google Me.

-جيرون

Answer 2

أعتقد أنه إذا قمت بنقل التطبيق الخاص بك إلى N-Tiers سيكون حلًا أفضل ، فسيكون الأمر أسهل بعد ذلك لاستخدامه بواسطة تطبيقات سطح المكتب وتطبيقات الويب.

لقد صنعت بالفعل الجزء الأول من خلال فصل منطق العمل من العرض التقديمي ، يمكنك استخدامه remobject SDK أو DataSnap التي تم تجميعها مع Delphi.

بعد ذلك ، سيكون لديك تطبيق لسطح مكتب العمل ، ويمكنك استخدام intrawebm ASP.NET أو أي شيء من أي وقت مضى لجزء الويب ، وبهذه الطريقة لن تضطر إلى تكرار منطق العمل مرة أخرى لجزء الويب.

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