من أجل التأكد من أنني ، بصفتي مطورًا من جانب الخادم ، أتحكم في كل شيء ، تمت كتابة الإصدار الأول من الخادم باستخدام فئة System.Net.Sockets.Socket ، كما توضح المقالة من Microsoft. نظرًا لأن المآخذ تعمل (من حيث المبدأ ، مثل جميع التقنيات الأخرى المدرجة بعيدًا عن Microsoft ، باستثناء WCF) في طرق البداية / النهاية ، تمت كتابة غلاف صغير يوفر القدرة على العمل مع النموذج المستند إلى الحدث. كانت هذه هي الخطوة الأولى ، حيث عمل العميل والخادم بشكل جيد.
منذ وقت قريب جدًا كنا في حاجة إلى SSL ، كان علينا الانتقال إلى مستوى أعلى من نموذج OSI وإعادة كتابة جانب الخادم باستخدام فئة System.Net.Sockets.TcpListener ، التي تم ربط SSL بها. كانت هذه الخطوات الثانية والثانية والنصف ، حيث عمل العميل والخادم بشكل جيد ، ولم يكن العميل بحاجة حتى إلى إعادة الكتابة - أظهر اعتراض الحزم أن كل شيء على ما يرام ، ولم يتغير شيء.
في وقت لاحق ، كنت أرغب في الحصول على HTTPS كامل بجميع أجراسه وصفاراته ، حيث تمت إعادة كتابة الخادم مرة أخرى - الآن باستخدام فئة System.Net.HttpListener هذه هي الخطوات الثالثة والثالثة والنصف ، ومرة أخرى كل شيء يعمل بشكل جيد ، ومرة أخرى لا يحتاج العميل إلى إعادة بنائه. من أجل الإنصاف ، تجدر الإشارة إلى أنه بالإضافة إلى عميل الهاتف المحمول المخصص ، كان هناك أيضًا عميل C # للاختبار ومجموعة من الاختبارات - ولكن كان يجب إعادة كتابتها بتكلفة.
جاءت الخطوة الرابعة عندما بدأنا في توسيع نطاق نظامنا في جميع الاتجاهات ، وأصبحت أغلفة التغليف الخاصة بنا عنق الزجاجة للمشروع. ثم قرأت عن WCF وفي إحدى الأمسيات (حسنًا ، تقريبًا) أعدت كتابة التفاعل بالكامل. من جانب العميل (وفي الحزم المرسلة) ، يظل كل شيء كما هو ، ولكن تم تقليل رمز جانب الخادم من ستة فئات جادة إلى بضعة أسطر.
هذه القصة لها نوعان من الأخلاق.
- (من الواضح) أن اختراع الدراجات أمر سيء. إذا ذهبت على الفور إلى Google ولم أكن أخشى استخدام تقنية جديدة لنفسي ، فسيكون من الممكن تقليل تطوير الخادم بنحو الثلث.
- (وهذا هو الشيء الرئيسي) مهمة تنفيذ نفس الآلية باستخدام أدوات مختلفة هي أفضل طريقة للتعلم ، مما يتيح لك تحقيق فهم عميق للموضوع. عندما تفعل شيئًا عدة مرات ، فإنك تتذكره. ولكن عندما تقوم في نفس الوقت بتعقيد (تغيير) الأدوات المستخدمة في كل مرة ، يتم شحذ المهارة بشكل أفضل.