ال .NET Framework عود على بدء

ال .NET Framework هي المحطة الأولى التي ينطلق منها أي مطور تطبيقات دوت نت لذلك فهو من أكثر الموضوعات التي يتم الاستفاضة في شرحها ألا أنه بطبيعة الحال فإن غالبية من يشرح لهم ال .NET Framework يكونوا من المبتدئين فبالتالي يحتاج فهم ال .NET Framework عندهم إلي وقت وممارسة فالصورة عندهم غير مكتملة وهناك بعض المعاني التي يحفظونها كما هي إلي أن يشاء الله ويفهمون هذه المعاني فهماً عميقاً وتضح عندهم الصورة، ولأني لست استثناء من هذه القاعدة أكتب هذا المقال بعد أن شاء الله وفهمت كثيراً من المعاني التي كان أقصى صدى لها في بداية تعلمي إياها هو نطقها فقط لذا كان من الأهمية بمكان كتابة مثل هذا المقال والمقسم كالآتي :
· الحياة قبل ال .NET Framework
· الحياة بعد ال .NET Framework
1- الحياة قبل ال .NET Framework
في هذه الأزمان كان على المبرمج أن يكون من نوعية – الكل في واحد - وأن يؤدي بمهارة أربعة أدوار وهي

البنّاء

المؤرخ

النصوح

المفتش

وهي بالطبع بجانب دوره كمبرمج ، ودعنا نفصل كل دور من الأربعة السابقة

1- يحتاج المبرمج أيامها أن يكون بنّاء لأنه سيبني بنفسه طريقة لإدارة الذاكرة وأخرى لإدارة الأخطاء بالإضافة لبناء كل سطر كود سيحتاجه البرنامج فلو قررت مثلاً بناء لعبة فعليك أن تبني نظام يتأكد من أن الذاكرة ليس فيها كائنات Objects غير مستعملة ونظام آخر لإدارة الأخطاء التي يمكن أن تنتج من اللعبة بالإضافة إلي بنائك لمحرك اللعبة ونظام الرسم على الشاشة وغير ذلك من مهام .

2- ولن يستقيم دوره كبناء بدون أن يكون مفتش جيد يعرف كيف يفتش عن خصائص نظام التشغيل الذي سيعمل عليه ونظام بناء نظام التشغيل فمثلاً إن كان 32-bitأم 64-bit وإن كان البرنامج سيعمل على أكثر من نظام تشغيل فيجب عليه أن يحيط علماً بكل الفروقات بين نظم التشغيل المختلفة فما يمكن عمله في Windows ME لا يمكن عمله في Windows NT فأبسط شئ يمكن ذكره هو عبارة عن اسماء مكتبات النظام System DLL التي يمكن ان يتغير اسمها من نظام تشغيل إلي نظام تشغيل آخر فبالتالي عليك أن تكون ملم بكل أسم لكل نظام تشغيل

3- يجب عليه دائما أن يكون ناصحا لزملائه بإتباع أساليب قياسية لتنفيذ برامجهم حتى يتسنى له التكامل مع برامجهم فاختلاف لغات البرمجة واختلاف طريقة بناء البرامج سببت مشكلة وهي عدم وجود اسلوب قياسي تستطيع من خلاله البرامج أن تتكامل مع بعضها البعض والأسلوب الأكثر شهرة هو ما يعرف بال COM (Component Object Model)

4- أخيراً لزاماً عليه أن يكون مؤرخاً لكل إصدارة من برنامجه ومكتبات النظام System DLL التي استعملها وتواريخ إصدار هذه المكتبات DLL حتى يمكنه نسخها إلي كل نظام تشغيل سيعمل عليه لأنه ياويل برنامجه إن بدل أحد المبرمجين غيره ملف من ملفات مكتبات النظام System DLL بملف آخر مختلف في تاريخ إصداره عن تاريخ إصدار ملف صاحبنا – هذه العملية عرفت بجحيم المكتبات DLL Hell -

أي أن ملخص هذا الكلام في أنه كان هناك عبء كبير ملقى على عاتق أي مبرمج نظراً لتوليه إنجاز كل هذه الأمور وأكثر بنفسه
- الحياة بعد ال .NET Framework
جاء ال .NET Framework حاملاً هدايا إلي ثلاث
1- إلي المبرمج فصدق أو لا تصدق فقد حمل عن كاهل المبرمج الأدوار الأربع هل تذكرهم أنهم:
    · البناء : فقد أعتمد ال .NET Framework في إراحة المبرمج من هذا الدور على مكونين أساسين

أ - نظام جديد لإدارة الذاكرة هو ال CRL (Common Language Runtime) وليس هذا فقط فقد تعدى هذه المرحلة إلي مرحلة أكبر وهي إدارة التشغيل بالكامل أي أنه منذ بداية تشغيل برنامجك وحتى إغلاقه فقد تولى ال CLR جميع مهام التشغيل من إدارة للذاكرة وإدارة للأخطاء وترجمة إلي لغة الآلة وغير ذلك.

ب - مكتبة جاهزة فيها تقريباً كل ما يحتاجه المبرمج لإنجاز مهامه وهي تعرف باسم FCL (Framework Class Library) أو BCL (Base Class Library) كلاهما صحيح ففي هذه المكتبة بنت مايكروسوفت فئات Classes جاهزة للاستعمال تتولى هي تنفيذ المهام التي كان على المبرمج أن يبنها بنفسه سابقاً مثل إدارة الاتصال مع قاعدة البيانات والرسم على الشاشة وغير ذلك من المهام

· أما عن دور المفتش فلم يعد له حاجة بعد ظهور أداة جديدة داخل ال CLR وهي ال JIT Compiler (Just In Time Compiler) ،

ودعنا نستوضح قليلاً دور المفتش هذا فقد كان ذا أهمية كبيرة سابقاً لأنه كان لزاماً علي أن أخرج البرنامج من تحت يدي وهو جاهز للتشغيل المباشر على أي نظام تشغيل يدعمه البرنامج أي أن ترجمة البرنامج من لغة البرمجة التي أعمل بها إلي لغة الآلة Machine Language تتم على جهاز المبرمج ثم توزع هذه النسخة المترجمة إلي لغة الآلة على الأجهزة المستهدف لتعمل عليه

ا أما بعد ال .NET Framework فقد اختلف الأمر حيث مازال يتم ترجمة البرنامج من لغة البرمجة إلي لغة أخرى على جهاز المبرمج ولكن هذه المرة لا يُترجم إلي لغة الآلة بل إلي لغة جديدة وهي ال MSIL(Microsoft Intermediate Language)

وهي لغة وسيطة يمكن لأي لغة برمجة تدعم ال .NET Framework أن يتم ترجمتها إلي MSIL ثم يتم توزيع البرنامج بعد ترجمته إلي MSIL لكن ال MSIL هي لغة لا يمكن تشغيلها بشكل مباشر على الحواسيب لذا يأتي دور ال JIT Compiler حيث يستطيع أن يترجم أي برنامج مكتوب بال MSIL إلي ال Machine Language

وفي هذه النقطة سؤال وهو طالما سيتم التحويل في النهاية إلي Machine Language فلماذا لم يتم هذا على جهاز المبرمج والأجابة هي "لرفع حمل دور المفتش" لأن من روائع ال JIT Compiler أن الترجمة التي تخرج منه بلغة ال Machine Language هي ترجمة تناسب نظام التشغيل الذي يعمل عليه ال JIT Compiler

أي أني لو بنيت برنامج وترجمته إلي MSIL ووزعته على ثلاثة من أصحابي أحدهم يشغل Windows XP والآخر Millennium ً Windows والثالث Windows Server 2003 وكل واحد منهم قد ركب .NET Framework على جهازه فإن ال JIT Compiler سيترجم لكل واحد منهم Machine Language تناسبه وبالتالي لن أحمل هم الإصدارات المختلفة من نظام التشغيل بعد الآن -

أما عن دور النصوح

فلن يعود صديقنا المبرمج بعد الآن إلي حمل هم نصح أصدقائه فقد جمعهم ال .NET Framework على منصة واحدة لها نفس المقاييس ويعود الفضل في توحيد أسلوب العمل بين كل المبرمجين الذين يبنون تطبيقاتهم باستخدام

ال .NET Framework إلي أن ال .NET Framework يخضع لمعايير تسمى

ال(Common Language Infrastructure) CLI وهذه المعايير وضعتها مايكروسوفت بنفسها وتم نشرها على www.ecma-international.org بحيث يجب على أي طرف يريد تطوير لغة تدعم الدوت نت أن يتبعها حيث لم تضيق مايكروسوفت نطاق تطوير لغات تدعم بيئية الدوت نت عليها وحدها بل فتحته لأي طرف يريد تطوير لغة يمكنها العمل على .NET Framework وبعد أن وضعت مايكروسوفت هذه الاشتراطات بدأت هي نفسها بتباعها لتبني أول نظام إدارة تشغيل متوافق مع معايير ال CLI وهو نظام إدارة التشغيل الذي يعرف باسم ال CLR ومن ضمن المعايير التي وضعها ال CLI معيار اسمه ال CLS (Common Type System) يخدم في المقام الأول معيار بناء لغة برمجة يمكن أن تعمل على .NET Framework وعكفت مايكروسوفت على بناء أول لغة يمكن أن تعمل على .NET Framework ومتوافقة مع معيار ال CLS وكانت C#.NET ثم اتبعتها مايكروسوفت بشقيقتها ال VB.NET وهما الاثنتين يمكن ترجمتها إلي MSIL

· ودور صديقنا المبرمج كمؤرخ

لم يعد يحتاجه بعد أن ظهر مكون من أهم مكونات ال .NET Framework تحدثنا عنه سابقا وهو ال (Base Class Library) BCL فكل ما ستحتاجه بعد الآن أن يستعمل الفئة Class التي تناسب عمله وعند توزيع البرنامج على أي عميل سيجد نفس الفئة Class موجوده على ال .NET Framework المركب عن العميل.

· كانت هذه الهدايا التي حملها ال .NET Framework إلي المبرمج فماذا في جعبته أيضاً

2- هدايا إلي أي مستخدم عادي لبرنامج تم بناءه بأي لغة تعمل على .NET Framework وهي كالتالي :

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

· لن يقع المستخدم في حيرة من أمره إن ظهر له رسالة تحذير من أن هناك برنامج يحاول تبديل واحدة أو أكثر من مكتبات النظام System DLL بواحدة أخرى أقدم ، فجميع برامج الدوت نت تستعمل ال BCL وهي موحدة على جميع الأجهزة ولا تختلف من جهاز لآخر

3- الهدية الثالثة حملها إلي البرنامج نفسه فلم يعد البرنامج يخزن بداخله جميع مكوناته فهو يحمل فقط الكود الذي كتبه المبرمج بيديه فقط أما كود إدارة الذاكرة فسيجده أينما يتم تركيبه موجود في ال .NET Framework وكود الفئات Classes التي يستخدمها من ال BCL سيجده أيضاً أينما تم تركيبه موجودا في ال .NET Framework