إعادة استخدام الخادم - DLL ، GAC ، أو الراحة؟

Question

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

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

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

1. ضع DLL (والتبعيات) في GAC. السؤال هو كيفية تكوين المكون. نظرًا لأن العملاء ليس لديهم مصلحة في التكوين ، فإننا نميل نحو تخزين ملف التكوين في مسار مشفر على الخادم.

2. نشر الوظيفة كخدمة داخلية (قائمة على الراحة). يمكن أن يقتصر الوصول إليها على العملاء الداخليين باستخدام جدار الحماية.

كما نرى ذلك ، يبدو أن إيجابيات #1 هي الأداء وربما الأمن ، في حين يمكن اعتبار رقم 2 أبسط.

هل نفتقد أي شيء مهم هنا؟ هل كان أي شخص في وضع مماثل من قبل ويريد مشاركة بعض البصيرة؟

Answer 1

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

1. من خلال جعل جميع عملائك يشتركون في ثنائي واحد ، سيتطلب الآن اختبار جميع عملائك في كل مرة تقوم فيها بإجراء تغيير عليها. الآن أعرف في حالتك الدقيقة أنه قد تضطر إلى القيام بذلك على أي حال لأننا يمكن أن نفترض أنك ستعدل قاعدة البيانات التي تقع خلف المكون.
2. لا ترمز إلى أي شيء. يمكنك تخزين مسار التكوين الخاص بك في قسم AppSettings في ملف machine.config.

أما بالنسبة للخيار 2 ، فإن بديل واحد هو استخدام WCF (على افتراض أن بيئتك يمكن أن تدعمها). باستخدام WCF ، يمكنك بعد ذلك استخدام نقل TCP باستخدام Servility ثنائي (وقد يكون هناك نقل ذاكرة مشتركة). كلاهما من شأنه أن يساعد في اقتراب فجوة الأداء (على الرغم من أن الخيار 1 سيتفوق دائمًا على نهج قائم على الخدمة).

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

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

يتيح لك الخيار 2 أيضًا توسيع نطاق الخدمة في المستقبل إذا كنت بحاجة إلى المزيد من طاقة وحدة المعالجة المركزية.

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

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

Answer 2

كما قال جوش بالفعل ، لسوء الحظ ، فإن إجابة هذه الأنواع من الأسئلة غالبًا ما تكون "يعتمد".

أنا معجب كبير بـ GAC ، لكن يجب عليك فقط وضع رمز هناك فقط من متأكد من أنه يعمل بشكل مثالي ، ولا يحتاج إلى تحديثه كثيرًا. طالما أن جزء من الكود "في التطوير" ، ما عليك سوى نشره مع كل تطبيق يستخدمه.

Answer 3

أود أن أقول إن استخدام الخيار 1 سيكون أكثر بساطة وأسهل ، خاصة وأن عليك فقط أن تقضي وقتًا إضافيًا في الحد من توفر الباقي. (يقصد التورية!)

Answer 4

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

هذه المشكلة هي بالضبط ما يفترض أن تحله الخدمية!