هل أحتاج إلى ناقل خدمة للتعامل البسيط مع الأوامر غير المتزامنة؟

Question

يستخدم نظامي نمط الأوامر مع معالجات منفصلة.يتم تنفيذ أوامري على CommandService الذي يتعامل حاليًا مع كافة الأوامر قيد المعالجة.

لدي أوامر معينة تقوم بتنفيذ واحد على الأقل من هذه الأشياء التي تعتبر عمليات بطيئة:

1. يرسل بريدا إلكترونيا
2. يولد قوات الدفاع الشعبي
3. يرسل فاكس
4. يتفاعل مع خدمات ويب الطرف الثالث

أريد أن يتم التعامل مع كل هذه الأوامر خارج العملية حتى تكون واجهة المستخدم أكثر سرعة.

هل يجب أن أستخدم ناقل الرسائل لهذه الأوامر فقط، أم يجب أن أقوم باستدعاء معالج الأوامر قيد التشغيل BeginInvoke()?

تحرير - معلومات إضافية

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

مع وضع الوضع برمته في الاعتبار، أعتقد أنني سأوافق على ذلك BeginInvoke() في الوقت الحالي لعدة أسباب:

1. يجب أن يتم لمس كافة تفاعلات واجهة المستخدم للتأكد من أنها تتصرف كما لو أن الأمر قد نجح.يوجد التذكير "بحاجة إلى إرسال هذا المستند" في أماكن متعددة في واجهة المستخدم ويقوم بتحديث الصفحة بالكامل بمجرد إرسال التقرير.
2. إنه منتصف الموسم المزدحم لعملائي (حيث يقومون بأكثر من 50% من أعمالهم السنوية في الصيف)، لذلك لا يبدو من الحكمة بالنسبة لي في هذا الوقت تقديم جزء جديد تمامًا من البنية التحتية التي لست على دراية بإدارتها .

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

Answer 1

كلا الحلين له إيجابياته وسلبياته.

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

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

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

Answer 2

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

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