لمبرمجي ASP.NET الذين يريدون برمجة تطبيقات Silverlight

الكثير من مبرمجي ASP.NET و أثناء تعلمهم لـSilverlight يبدؤون بمقارنة كل سمة من سمات Silverlight بنظيرتها في ASP.NET، كيف نتعامل مع كذا، كيف نقرأ قيمة كذا، … إلخ.
هناك ناحية أساسية قرأت عنها و أردت التنبيه لها لأن الكثيرين لا ينتبهون لها رغم أهميتها، و هي سرّية الكود الذي تكتبه لتطبقات سيلفرلايت.

ما المشكلة؟
لشرح المشكلة سنتذكر الطريقة التي يتم تنفيذ تطبيقات ASP.NET بها، بشكل بسيط و مختصر، يقوم السيرفر بتنفيذ كود البرنامج و إظهار النتائج على شكل HTML يتم إرسالها إلى العميل ليقوم متصفحه بعرضها بالطريقة المطلوبة، أي أن “جميع” العمل يتم تنفيذه على السيرفر.
و أما بالنسبة لسيلفرلايت، الحال باختصار هو أن الكود و بعد أن تتم ترجمته إلى لغة MSIL يتم تخزينه على السيرفر على شكل ملفات DLL، و عندما يطلب العميل صفحة أحد تطبيقات سيلفرلايت، يتم إرسال الكود و ملفات XAML إليه لتقوم إضافة سيلفرلايت بتشغيلها على جهاز العميل نفسه.
ماذا يعني هذا؟ يعني أن أي تطبيق سيلفرلايت يمكن أن يخضع للهندسة العكسية و فك ترجمته Decompiling، مثله مثل أي تطبيق دوت نيت عادي، و هذا يعني بدوره أن “عليك” ألا تضع أي كودات لها أهمية (خورازميات خاصة بك، طرق التشفير، …) ضمن كود تطبيقات سيلفرلايت التي تكتبها.

ما الحل؟
الحل ببساطة أن تقوم بإنشاء Web Service تحوي الكود الذي تريد الإحتفاظ به لنفسك، و من ثم استدعاؤها عن طريق تطبيق سيلفرلايت. هذه الطريقة آمنة تماماً لأن العميل لن يطلع على الكود و لن يتم تنفيذ أي جزء منه على جهازه، سيكتفي بإرسال المعطيات إلى السيرفر حيث ستتم معالجتها هناك و من ثم إرسال النتيجة مرة أخرى إليه.

ما مساوئ هذه الطريقة؟
السيئة الأولى هي بطء تنفيذ عمليات البرنامج بالنسبة للعميل، فبدلاً من تنفيذ العملية على جهازه مباشرةً، سيضطر لإرسال معلومات إلى السيرفر لنفذ هناك و من ثم تعاد النتائج له، و هذا سيستغرق وقتاً أطول طبعاً.
السيئة الثانية هي الحمل الذي سنكلفه للسيرفر و الذي سيكون دوره مقتصراً على إيصال الملفات في حالة تطبيقات سيلفرلايت التي لا تستخدم Web Services.
إذن عليك أن تقوم بموازنة هاتين السيئتين لطريقة الـWeb Service مع سيئة قلة أمان الكود في تطبيقات Silverlight لتختار و بحكمة أين سيتم تنفيذ كل جزء من أجزاء برنامجك، حظاً موفقاً.