الشمس المشرقة الأبدية للشبكة النظيفة

عندما بدأت العمل مع .NET Framework 3.5 (إصدار اللغة 3.0) قبل 10 سنوات ، كانت وظيفتها محدودة للغاية بالنسبة لي ، حيث بدأت مع SharePoint 2010. أدرس تدريجيًا مجموعة واسعة من التقنيات ومتابعة تطوير .NET ، وأنا يمكنني ملاحظة نموها الهائل من منافس مشكوك فيه إلى Java إلى نظام أساسي رائع مع القدرة على تطوير الشياطين لنظام Linux (وكان مخصصًا حصريًا لنظام Windows). بالطبع ، عندما واجهت التكنولوجيا لأول مرة ، بدا أن كل شيء كان كافيًا: بعد كل شيء ، كانت هناك طرق لتنفيذ ما هو مقصود. ولكن الآن ، وبعد أن اكتسبنا خبرة في العمل على منصات مختلفة وإصداراتها المختلفة ، يمكننا بالفعل التكهن بأن الحياة كانت ألمًا في تلك الأوقات البعيدة.

بشكل عام ، إذا كان من المثير للاهتمام العودة عقلياً إلى تلك الحقبة والتأمل في .NET معًا في سياق "لقد كان - لقد أصبح" ، فأنا أدعوك إلى المشاركة. أعتقد أنه سيكون من المثير للاهتمام لكل من يقوم بالترميز مؤخرًا ولا يعرف عن ميزات الإصدارات السابقة ، ولمن يرغب في الانغماس في الحنين إلى الماضي.

عصر الألم

عندما بدأت التطوير ، عمل SharePoint 2010 على .NET Framework 3.5 وتضمن بالفعل الكثير: ظهر LINQ وكان هناك AJAX بدائي. لكن المنصة كانت محدودة للغاية ، حيث كان من الصعب توسيعها ، ولم تكن هناك أدوات كافية.

الألم 1: إنشاء تطبيق واحد

ثم اعتمدت تقنية تطوير أجزاء الويب الخاصة بـ "ball" على WebForms ، مع كون كل جزء ويب عبارة عن تطبيق منفصل بشكل أساسي. شخصيا ، كان من غير الواقعي أن أقدم تطبيقًا واحدًا كهذا ، لأنه عند تطوير جزء الويب ، يقوم كل منهم بتهيئة سياقه الخاص للاتصال بقاعدة البيانات - اتضح أنه كان من المستحيل إنشاء سياق واحد. حسنًا ، على سبيل المثال ، لعرض البيانات من قاعدة البيانات على الصفحات ، استخدمت SqlDataSource (عن طريق الاتصال بقاعدة البيانات في عنصر واجهة المستخدم بشكل منفصل) ، وللاتصال بجداول 3-4 ، كان لدي 3-4 DataSource على القطعة ، والتي بالطبع تتأثر سرعة تحميل الصفحة. بحلول ذلك الوقت ، كان ADO.NET Entity Framework قد ظهر بالفعل ، لكن كان من غير المناسب استخدامه في SharePoint حتى الإصدار 4.1 ، لأن كانت هناك مشاكل مع تفاعل المنتجات.

الألم 2: عدم إمكانية الوصول إلى الدعم والأنماط

أجزاء الويب لـ SP 2010 كتبناها حول تقنية إنشاء جزء ويب SP 2007 ، لأنه لم تكن هناك قوالب أو دعم لاستوديو 2008. تدريجيا ، مع إصدار Visual Studio 2010 ، ظهرت قوالبهم ، وأصبح العمل أسهل: أصبح من الممكن عمل تعريفات القائمة وترميزها من الاستوديو ، لإنشاء قالب موقع (ترميز نوع المحتوى ووصف القائمة المطلوب). في السابق ، كان كل ذلك يتم من خلال تحرير ملفات XML ، وهذا ، بلا شك ، كان الألم بالنسبة لأولئك الذين كانوا منغمسين في تطوير .NET ، لأن الشخص لم يفهم نوع الملف الذي كان يحرره ولأي غرض ، لكنه ركز فقط على كلمات العم من المنتدى.

الألم 3: عدم التزامن ...

في .NET Framework 3.5 ، لم يكن هناك تزامن في الشكل الذي نعرفه الآن ، وكان علينا تشغيل تعليمات برمجية معينة في سلسلة رسائل أخرى ، والتواصل من خلال معالجات المفوض ، وفي WinForms ، كان من الممكن استخدام خلفية العامل (مثل العملية الثانية يعمل بالتوازي مع تنفيذ العمل). اتضح أن برمجة التطبيقات غير المتزامنة كانت موجودة ، لكن تنفيذها لم يكن يفهم يونيو.

في .NET Framework 4 ، ظهرت مكتبة Parallel Task ، وبالتالي ظهرت المهام أيضًا ، أي لم نتمكن من التصريح عن المندوبين ، ولكننا نقوم بمهمة ، وننقل العمل إليها ، وننفذها في خيط موازٍ ، ونعرف الحالة / الحالة ، وعند الضرورة ، نتلقى إشارة حول تنفيذها. لقد كان التقدم من أجل التطوير المتوازي ، عندما تحتاج إلى معالجة كمية كبيرة من البيانات ، لأنه قبل أن يتم ذلك باستخدام شريط إدخال أكبر.

... والنوافذ المجمدة

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

الألم 4: النشر قادم

أيضًا في .NET Framework 3.5 كانت هناك تقنية مؤلمة أخرى - MS AJAX. تم تحديث محتوى UpdatePanel من الخلفية ، بينما لم يتم إعادة بناء كل شيء آخر على الإطلاق. في SharePoint ، عمل بطريقة ملتوية للغاية بسبب تفاصيل تهيئة عناصر التحكم في دورة حياة الصفحة. هنا نجح الأمر بالنسبة لنا بعد أول مرة بعد الظهر (أحيانًا بعد الثانية) ، وكان من الصعب بشكل عام جعل MS AJAX يعمل بشكل جيد في المرة الأولى ، على الرغم من أنه تم استخدامه ببساطة مع WebForm UpdatePannel النظيف. ولم يكن من الممكن استخدام AJAX الكلاسيكي (XMLHttpRequest) في هذا الإصدار من "الكرة" ، لأنه لكل إجراء كان من الضروري كتابة معالج منفصل على ظهره وتعليقه في حزمة من كل جزء ويب. في الوقت نفسه ، لم يكن من الممكن دائمًا إنهاء هذه الوظيفة.

عندما كنت أعمل بالتوازي مع التطبيقات الأخرى المكتوبة على WebForms من أجل المهام "القريبة من الكرة" ، فوجئت بأن مشكلة نشر مشروع إلى SP هي مشكلة لـ SP فقط. تمت تهيئة بقية التطبيقات في الوقت الحالي: تم تحميل النافذة ، ويعمل (السحر!). في البالون ، استغرق النشر من 2 إلى 3 دقائق ، وأنت في دورة ثابتة:



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

الألم 5: ويندوز وليس سوى ويندوز

في ذلك الوقت ، كان .NET لا يزال يحتل موقعه كمنصة تطوير لنظام Windows. نعم ، كان هناك مشروع Mono ، والذي كان في جوهره "دراجة" على .NET على Linux ، لكنه كان نسخة بديلة من الإطار الرئيسي ، ولا يزال على صفحة المشروع www.mono-project.com/docs/ about-mono / التوافق ) يسرد الميزات التي لم تتم إضافتها إليها بواسطة إصدار Framework. عندما طورت شيئًا لنظام Linux ، كان هذا بعيدًا عن سهولة استخدامه ، نظرًا لأن Mono لم يكن لديه هذا الدعم والمجتمع ، وإذا تحولت إلى بعض الأشياء غير المحققة ، فيمكنك ببساطة كسر الشفرة. أي إذا لم تقم بتطويرها لـ Mono في البداية ، فلن تتمكن من كتابة التعليمات البرمجية المستقلة عن النظام الأساسي. لا أستبعد أهمية هذا المشروع في تطوير .NET ككل ، لأنه بدونه لم يظهر Core ، لكن شخصياً ، لم يكن لدي أي خبرة قتالية معه.

عصر الايجابيات (مسكن للألم)

إن استخدام أحدث إصدار من .NET pure في مشاريعهم يزيل كل هذه المشكلات تقريبًا. هناك العديد من المزايا الإضافية في Framework الآن ، ولكن بعد ذلك سنتحدث عن المزايا المرتبطة بـ Core ، مثل لقد عملت معه.

زائد 1: الأداء

عندما ظهر .NET Core ، أصبح من الممكن القيام بعمليات مألوفة أكثر برودة وأسرع. تعمل التطبيقات النهائية على ذلك وفقًا لبعض البيانات التي تصل إلى 5000 مرة أسرع من نظيراتها على .NET Framework. لكن التجميع والإطلاق يستغرقان وقتًا أطول - "تسخير لفترة طويلة - قم بالقيادة بسرعة".

زائد 2: عبر منصة

تتمثل الميزة الرئيسية لبرنامج .NET Core في حقيقة أن التعليمات البرمجية المكتوبة تعمل في وقت واحد على أنظمة Windows و Linux و Mac. في هذه الحالة ، يمكنك كتابة تطبيق على بنية microservice لخدمة التسجيل غير المتزامن من خلال قائمة انتظار الرسائل. أتذكر كيف أنني ، المطور الذي يكتب بشكل أساسي تحت Windows ، كتب الشياطين (الخدمات) في نظام Linux ، وعملوا بشكل مستقر وسريع وأول مرة ، والنظام بأكمله يعمل بالترادف: في التطبيق وخدمة API وقائمة انتظار الرسائل نفسها. إنه مجرد مساحة ، عندما تكتب بلغتك المعتادة على نظام أساسي لم يتم تصميمه أصلاً لنظام التشغيل هذا!

زائد 3: المتزامن من كل شيء

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

زائد 4: تفريغ المكتبات واستهلاك أقل كثافة الذاكرة

إذا نظرت إلى الإصدار الثامن الحالي من C # ، فستحتوي على الكثير من السكر ، والتغييرات رائعة. أولاً ، قبل أن لا تكون لدينا القدرة على إلغاء تحميل DLL التي تم إلغاء تحميلها بشكل حيوي (تم تحميل المكتبات بشكل ديناميكي في المشروع ، لكنها ظلت معلقة في الذاكرة). مع إصدار 3rd Core ، أصبح من الممكن تحميل المكتبات وتفريغها ديناميكيًا وفقًا للأهداف. على سبيل المثال ، إذا كنا نرغب في إنشاء تطبيق للبحث عن الملفات ، وكان المستخدم يختار امتداد XML ، فنحن نقوم بتحميل مُحلل XML ديناميكيًا للوثائق والبحث في الشجرة الخاصة به. إذا كنا نريد البحث عن طريق JSON ، فإننا نبدأ في البحث عن طريق مكتباتها التي تعتمد على شروط معينة ، وليس هناك حاجة إلى الاحتفاظ بها في ذاكرة الوصول العشوائي. ونعم. توقف التطبيق عن استهلاك الذاكرة باستمرار. عندما نفرغ التجميع ، فإننا نحرر كل الموارد التي تتشبث بهذا التجميع.

زائد 5: tuples

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

لتلخيص!

يوجد لدى العديد من المطورين مثل هذا الموقف تجاه التغييرات اللغوية: إلى أن ننجح بشكل جيد ، لم نكن نعرف ما هو السيئ. .NET Core هو مصدر مفتوح ، لذلك يمكن لأي شخص إضافة ميزة بنفسه ، والكتابة عن آلامه على البوابة. بالطبع ، هناك الكثير من القضايا المثيرة للجدل: شخص ما ينتظر تغييرات تبدو غير مريحة تمامًا للآخرين. على سبيل المثال ، يتضمن الإصدار 8 من اللغة التحكم في أنواع Nullable Reference ، وحتى الآن تعتبر مسألة الملاءمة مثيرة للجدل: تم الإعلان عن الابتكار في نسختين سابقتين ، وتم إدراجه فقط في الإصدار 3.0 الأساسي النهائي ، وتم تعطيل هذه الميزة افتراضيًا ، حيث قد يتم تضمينها إلى انهيار مشروع كبير. ولكن عند كتابة طلب من نقطة الصفر ، فإنه مفيد للغاية ويسمح لك بجعل التطبيق أكثر نظافة وشفافية.

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