برای یادگیری هر زبانی، نیاز است تا مقدمات و مفاهیم اساسی و همچنین استاندارد های آن را بیاموزیم. در این مقاله با استاندارد های NET. آشنا می شویم و نکاتی را درباره آن ها می آموزیم.

TL;DR :

استاندارد Net. مشکلاتی مشترکی که بین همه توسعه دهندگان Net. در تمام پلتفرم ها وجود دارد را با آوردن APIهای مورد نیاز و سازگار با محیط ، حل میکند :
برنامه های desktop , برنامه های موبایل و باز ی ها و سرویس های اَبری :

- Net standard. مجموعه ای از APIها هستند که Net Platform. باید آنها را پیاده سازی کنند . این کار Net Platform. را یکپارچه میکند و از شکاف و اشکالاتی که ممکن است در آینده رخ دهد ، جلوگیری میکند . 

-  Net Standard 2.0. توسط Net Framework. و Net Core. و Xamarin برای Net Core. پیاده سازی خواهد شد ، این خیلی از API های موجود را که مورد نیاز هستند را اضافه خواهد کرد .  

- Net Standard. برای ایجاد کتابخانه های multi-platform ، کتابخانه های کلاس های Prtable را تحت عنوان tooling story ها جایگذاری خواهد کرد . 

به چه دلیل ما به استاندارد ها نیاز داریم ؟

همانطور که در مقاله های قبلی هم ذکر کردیم ، Net platform. در طی سال ها به چندین شاخه تقسیم شده است . که این دارای یک مزیت است که میتوان بر اساس نیاز این شاخه ها را در کنار یکدیگر قرار داد و استفاده کرد ، که این امر برای یک platform تنها امکان پذیر نیست . برای مثال ، Unity (یک شاخه از Mono) بر روی بیش از 20 پلتفرم قابل اجرا میباشد . امکان شاخه شاخه و سفارشی کردن ظرفیتِ مهمی است که میتواند تمام نیاز های یک تکنولوژی را مرتفع سازد . 

اما در سوی دیگر ، یک مشکل بسیار بزرگ در کد نویسی برای توسعه دهندگان وجود داشت که یک کتابخانه واحد برای پلتفرم های Net. وجود ندارد . 

در حال حاضر سه رشته اصلی از Net. وجود دارد که برای نوشتن کدهایی که در همه ی این پلتفرم ها کار کند سه کتابخانه بنیادی در اختیار شما قرار میدهد . 
در تصویر زیر جاهایی را میبینید که Net Standard. کارآمد می باشد :

برای برنامه نویسان، این گفته به این معنا است که آن ها فقط نیاز دارند تا یک class library پایه را مدیریت کنند. کتابخانه هایی که بر  پایه ی NET. استاندارد باشند می توانند بر روی همه پلتفرم های NET.  اجرا شوند و نیازی به API های مجزا ندارند. 

• برنامه ها - در مورد برنامه ها ، شما مستقیما از NET. استاندارد استفاده نمی کنید ولی از مزایای آن به صورت غیر مستقیم می توانید بهره مند شوید. ابتدا NET. استاندارد مطمئن می شود که همه ی پلتفرم های NET. از یک نوع API یکسان برای class library پایه استفاده می کنند. برای استفاده از آن ، کافی است تا فقط یک بار نحوه استفاده از آن را یاد گرفته و به خاطر بسپارید. بعد از انجام این کار، اغلب Class  library  های مربوط به NET. استاندارد در تمامی بستر ها در دسترس خواهند بود. 

• Class  library های Portable - بیایید ابتدا کمی راجع به نحوه کار Portable Class Libraries (PCL) در دنیای امروز صحبت کنیم. با استفاده از PCL ، شما پلتفرم مورد نظرتان را برای اجرا انتخاب می کنید و سپس مجموعه ی API های مورد نظرتان در اختیار شما قرار می گیرد. با استفاده از NET. استاندارد ، شما یک Class  library خواهید داشت که بر روی همه ی پلتفرم های NET. پشتیبانی می شود. نکته مهم دیگر این است که هر چقدر نسخه ی برنامه شما بالاتر باشد، به API های بیشتری نیز نیاز خواهید داشت. اما در  NET. استاندارد ، این طور نیست. به دلیل یکپارچگی بین پلتفرم ها، نیاز به استفاده از API های متعدد نیست. 

• نسخه بندی و استفاده از ابزارها - هدف از ایجاد و توسعه ی NET Core. این بود که یک پایه و اساس برای portable .NET platform ایجاد کنیم تا به این ترتیب ساختار بندی و پیاده سازی API ها یکسان شوند. در حقیقت، ما می خواستیم آن را تبدیل به نسخه بعدی Portable Class Library ها کنیم. اما متاسفانه در زمینه استفاده از ابزار ها در آن ، چندان موفق نبودیم. چون هدف ما پوشش دهی همه ی پلتفرم ها بود، بنابراین لازم بود  تا آن ها را به Nuget Package های کوچک دسته بندی کنید. اگر همه این کامپوننت ها به خوبی کار کنند، برنامه می تواند از آن ها به صورت مستقل بهره ببرد. اما ممکن است در صورتی که برای یکی از کامپوننت ها نسخه خاصی تعریف کرده باشید، برنامه با مشکل رو به رو شود ، که برای جلوگیری و حل این مشکل ، بخش های مختلف در قالب Nuget package های متنوع ارائه شده اند. در حقیقت، در این مورد، نسخه بندی برنامه همانند سطح API عمل می کند. 

اگر بخواهیم چکیده ای از مطالب بالا را بیان کنیم، 

1-ایجاد اجبار برای پیوستگی . همه ی پلتفرم های NET. موظف هستند تا API های مورد نیاز را پیاده سازی نمایند تا به این ترتیب بتوانند به محیط  .NET library دسترسی داشته باشند. 

2-پایه و اساسی برای ابزارهای cross-platform . ما یک سری ابزارهای ساده و کارآمد نیاز داریم تا همه ی پلتفرم های NET. بتوانند از یک نسخه واحد آن استفاده کنند. 

موارد جدید در .NET Standard 2.0 

در جدول زیر می توانید ببینید که هر کدام از پلتفرم ها با کدام یک از نسخه های .NET Standard مطابقت و همخوانی دارند.

فلش هایی که در جدول وجود دارند، نشان می دهند که آن پلتفرم، از نسخه بالاتری از .NET Standard پشتیبانی می کند. به عنوان مثال، .NET Core 1.0 از نسخه ی  .NET Standard 1.6 پشتیبانی می کند که به همین دلیل فلش هایی در کنار آن قرار داده شده اند. 

با استفاده از جدول بالا و همچنین پلتفرمی که در حال کار با آن هستید، می توانید نسخه ی  .NET Standard مورد نظرتان را شناسایی کنید. 

.NET Standard همچنین با Portable Class Library ها نیز سازگاری و مطابقت دارد. 

اگر کتابخانه ای شامل  .NET Standard باشد، شما می توانید دو نوع از کتابخانه های دیگر را در آن استفاده کنید:

.NET Standard : اگر نسخه های آن ها مساوی و یا پایین تر از نسخه ی Class Library شما باشد. 

Portable Class Libraries : اگر پروفایل آن ها قادر به نگاشت دهی به نسخه ی .NET Standard باشد و نسخه آن مساوی و یا پایین تر از نسخه ی Class Library شما باشد. 

اگر بخواهیم این موارد را به صورت گرافیکی نمایش بدهیم، به صورت زیر خواهند بود:

در  .NET Standard 2.0 ما قابلیت دیگری اضفه کرده ایم که می توان از .NET Standard  همراه با refrence های موجود در .NET Framework استفاده کرد، بدون آن که هیچ گونه تعارضی در بین ان ها به وجود بیاید. 

اما مسلما این رابطه زمانی برقرار است که کتابخانه های NET Framework. از API هایی استفاده کنند که در NET Standard نیز در دسترس باشند. 

تغییرات لحظه ی آخری NET Standard 2.0 : اضافه شدن سازگاری با .NET Framework 4.6.1

یکstandard  از آنجایی مفید است که برای همه ی پلتفرم هایی که آن را پیاده سازی می کنند، به صورت یکسان عمل می کند. این ویژگی برای ما بسیار مفید است زیرا API ها هستند که در نهایت با این استاندارد سر و کار خواهند داشت:

NET Framework. :  

NEt Framework 4.6.1 بهترین انطباق را دارد و به همین جهت، جذاب ترین نسخه محسوب می شود. اگرچه می خواهیم ابتدا مطمئن شویم که بتواند پیاده سازی های مربوط به .NET Standard 2.0 را انجام بدهد. 

.NET Core:

همان طور که در بخش های قبل نیز اشاره شد، NET Core. یک مجموعه API کوچکتر از NET Framework و یا Xamarin دارد. برای این که بتوانیم از همه ی API  های NET Standard 2. استفاده کنیم، باید SDK  های مربوطه را به روز رسانی کنیم. 

Xamarin :

Xamarin در حال حاضر نیز اغلب API های موجود در NET Standard 2.  را پشتیبانی می کند. اما برای این که بتوانیم به همه ی API ها دسترسی داشته باشیم، لازم است آن را به روز رسانی کنیم.

موارد موجود در NET Standard. :

برای این که بتوانیم تصمیم بگیریم کدام API ها بخشی از NET Standard. خواهند بود، از پردازش های زیر استفاده می کنیم:

• Input (ورودی) :

ما با API هایی شروع می کنیم که هم در NET Framework.  و هم در Xamarin در دسترس هستند. 

• Assessment (ارزیابی) :

ما همه ی API ها را در دوسته زیر دسته بندی می کنیم:

Required (اجباری ) :

API هایی که ما می خواهیم همه ی پلتفرم ها آن را پشتیبانی کنند و باور داریم که باید به صورت cross-platform پیاده سازی شوند، با نام اجباری شناخته می شوند. 

Optional (دلخواه) :

API هایی که مخصوص یک پلتفرم خاص و یا بخشی از یک تکنولوژی مستقل هستند، را به نام optional می شناسیم. 

API های Optional بخشی از NET Standard. نیستند ولی در قالب Nuget Package های جداگانه در دسترس هستند. 

برای این که بتوانیم API هایی را به شکل Optional دربیاوریم، ممکن است لازم باشد API های اجباری را از آن ها حذف کنیم. 

در زیر محدوده ی API ها در NET Standard 2.  نشان داده شده است:

آیا ما همچنان می توانیم از API های مخصوص پلتفرم ها استفاده کنیم؟

یکی از بزرگ ترین چالش ها برای class Library های چند پلتفرمی ، جلوگیری از به وجود آمدن بخش های مشترک (بیش از حد مجاز) است. 

سوالی که در اینجا ممکن است پیش بیاید این است که چرا برخی از API ها نمی توانند بر روی همه پلتفرم ها پیاده سازی شوند:

API های ویژه ی زمان اجرا:

به عنوان مثال، توانایی ایجاد و اجرای کد با استفاده از reflection emit. این ویژگی نمی تواند بر روی پلتفرم های NET.  اجرا شود زیرا کامپایلر JIT در آن ها وجود ندارد. 

API های ویژه ی سیستم عامل :

در NET.  از win32 ما شاهد ظهور API  های بسیاری بودیم. یکی از مثال های خوب در این زمینه،  Windows registry است. پیاده سازی آن بستگی به  Win32 API های زیرین دارد. 

در NET Core. اوضاع به چه صورت است؟ 

NET Core. به گونه ای طراحی شده است که reference assembly های آن به صورت Portable هستند. این ویژ گی ، کار ما را برای اضافه کردن API  ها دشوار می کند، زیرا در ابتدا قابلیت Portable بودن این API  ها سنجیده می شود. همچنین به دلیل وجود نسخه بندی های متفاوت ، ما باید نسخه ی API ها و همچنین میزان سازگاری آن ها با نسخه های برنامه را نیز بررسی کنیم. 

Out-of-band delivery:

ما تلاش کردیم تا با استفاده از Out-of-band delivery ، استفاده از API ها را امکان پذیر نماییم. این کار به این معنی است که ما آن ها را به صورت کامپوننت های جدیدی می سازیم که می توانند در کنار API های موجود قرار بگیرند. 

بهره گیری از ویژگی های زمان اجرا:

در این زمینه، کار تا حدود زیادی دشوار تر است ، زیرا نمی توانیم این API ها را در قالب Nuget Package  های مختلف به کاربر بدهیم تا از آن ها استفاده کند. در کنار این مورد، لازم است تا یک روش برای اجرای آن در زمان اجرا نیز ارائه شود. این کار در پلتفرم هایی که یک زمان اجرای گسترده دارند (مانند NET Framework. ) دشوار تر است. اما به طور کلی زمان اجراها برای اعمال مختلف نیز تا حدود زیادی متفاوت هستند. 

جداسازی  .NET Standard از .NET Core:

برای این که بتوانیم به توسعه ی NET Core. به صورت مستقل از سایر پلتفرم های NET. بپردازیم، ما مکانیزم Portabaility را باید پیاده سازی نماییم. .NET Standard به عنوان یک  reference assembly مستقل تعریف شده است که نیازهای سایر پلتفرم های NET. را برآورده می کند. هر پلتفرم NET. از یک مجموعه خاصی از reference assembly دارد و بنابراین می تواند به صورت آزادانه ، API های جدیدی را اضافه کند .

جداسازی قابلیت Portability از  .NET Core  به ما کمک می کنند تا روند توسعه را سرعت ببخشیم و ویژگی های جدید را به آسانی تجربه کنیم. 

هدف ما از توسعه ی NET Standard. این است که یکپارچگی قوی ای بین پلتفرم های NET. ایجاد کنیم و این یکپارچگی را نیز حفظ کنیم. 

آموزش سی شارپ