آیا باید از NET Standard. خداحافظی کنیم

با اعلان .NET 5 در سال گذشته و اعلان‌های بعدی منتهی به MSBuild 2020، یک سوال بزرگی که پیش می‌آید این است که چه اتفاقی برای " NET Standard." می‌افتد.

چرا ما NET Standard. را داشتیم

بیایید یک قدم به عقب برگردانیم و ببینیم چگونه و چرا NET Standard. به وجود آمد.

وقتی NET Core. برای اولین بار منتشر شد، معضلی پیش آمد. ما تمام این کتابخانه‌ها را داریم که قبلا برای NET Framework. نوشته شده است، آیا واقعا می‌خواهیم همه آن‌ها را دوباره برای NET Core. بنویسیم؟ با توجه به اینکه اکثریت NET Core. اولیه بخشی از NET Framework. برای کار cross platform بود، بسیاری از signatureهای (امضاء) متدها و کلاس‌ها یکسان بودند (تا جایی که می‌توانیم بگوییم بیشتر آن‌ها بودند).

بیایید یک مثال بزنیم. بیایید بگوییم که می‌خواهیم فایلی را با استفاده از فراخوانی استاندارد File.ReadAllLines(string path) درون کتابخانه خود باز کنیم. اکنون این اتفاق می‌افتد که اگر شما این کد را درون NET Framework.، NET Core. یا حتی Mono بنویسید، این همان پارامترها را می‌گیرد (یک متغیر string path)، و همان چیز را برمی‌گرداند (یک آرایه رشته‌ای). حالا چگونه این خواندن فایل را فراخوانی می‌کند که برای پلت‌فرم خاصی است (مثلا NET Core. و Mono ممکن است دارای کد خاصی برای مسیر فایل‌های مک داشته باشند)، اما نتیجه باید همیشه یکسان باشد، یک آرایه رشته‌ای خطوط از فایل.

پس اگر ما کتابخانه‌ای داشته باشیم که کاری نمی‌کند جز اینکه یک فایل را برای خواندن خطوط و برگرداندن آن باز می‌کند، آیا واقعا باید این کتابخانه را چندین بار برای فریم‌ورک‌های مختلف منتشر کنیم؟ خوب، اینجا جایی است که NET Standard. وارد می‌شود. ساده‌ترین راه برای فکر کردن در مورد آن، تعریف لیستی از کلاس‌ها و متدهایی است که هر پلت‌فرم برای اجرای آن موافقت می‌کند. بنابراین اگر File.ReadAllLines() بخشی از استاندارد باشد، پس می‌توانیم مطمئن شویم که کتابخانه ما می‌تواند فقط یک بار به عنوان کتابخانه NET Standard. منتشر شود، و روی چندین پلت‌فرم کار کند.

NET Standard. راهی برای پلت‌فرم‌های مختلف NET. ارائه می‌دهد تا مجموعه‌ای از signatureهای رایج متد را به اشتراک بگذارند که به سازندگان کتابخانه این امکان را داده است تا یک بار کد را بنویسند و آن را بر روی پلت‌فرم‌های مختلف اجرا کنند.

NET Standard. دیگر لازم نیست

حالا که ما به امروز رسیده‌ایم می‌شنویم که NET Standard. دیگر لازم نیست. و دو دلیل اصلی برای این امر وجود دارد:

عملکرد NET Core. از NET Framework. فراتر رفته است. یعنی نسخه‌های جدید NET Standard. سخت به دست می‌آیند.

در ابتدا، NET Core. زیرمجموعه‌ای از عملکرد NET Framework. بود. بنابراین NET Standard. یک روش تقریبا اظهار شده بود، اگر شما کتابخانه‌ای برای NET Framework. نوشتید، چطور شما می‌دانید که بدون تنظیمات خاصی برای NET Core. کار خواهد کرد. بله، NET Standard. نیز به عنوان راهی برای دیدن عملکرد در پلت‌فرم‌های دیگر مثل Mono، Xamarin، Silverlight و حتی Windows Phone استفاده می‌شد. اما ما فکر می‌کنیم بیشتر موارد استفاده برای تطبیق NET Framework => .NET Core. بود.

همان‌طور که NET Core. قابلیت‌های خود را ایجاد کرده است، در اصل هنوز هم سعی در دستیابی به تساوی ویژگی با NET Framework. را داشت. بنابراین به محض انتشار نسخه جدیدی از NET Core. در هر سال، نسخه جدیدی از NET Standard. نیز با آن منتشر می‌شد، که تقریبا تنها به دنبال signatureهای متداول متد در میان NET Framework <=> .NET Core بود. بنابراین در نهایت NET Core. از NET Framework. فراتر رفت، یا حداقل می‌گوید "ما هیچ چیز اضافی را حمل نمی‌کنیم. این مرحله در اصل NET Standard 2.0. است.

اما بدیهی است که NET Core. متوقف نمی‌شود و ویژگی‌های جدیدی به NET Core. اضافه می‌شود که در NET Framework. نیستند. اما آپدیت‌های NET Framework. در ابتدا کم هستند و فاصله بین آن‌ها زیاد است. بنابراین با اضافه شدن ویژگی‌های‌ جدید به NET Core.، آیا آن‌ها منطقی را می‌سازند تا به نسخه جدید استاندارد اضافه شوند با توجه به اینکه NET Framework. هرگز آن استاندارد را پیاده‌سازی نخواهد کرد؟ تا حدی... یا حداقل آن‌ها سعی کرده‌اند. NET Standard 2.1. آخرین انتشار استاندارد بود و توسط Mono و Xamarin پیاده‌سازی شد، اما نه توسط NET Framework.

بنابراین حالا ما استانداردی داریم که برای توصیف برابری بین دو پلت‌فرم بزرگ ابداع شده، که یک پلت‌فرم دیگر نمی‌خواهد در آن شرکت کند. منظور ما این است که می‌توانیم استانداردهای جدید را پیاده‌سازی کنیم اما اگر فقط یک بازیکن وجود داشته باشد، پس این نوعی دادخواهی است.

ادغام پلت‌فرم‌های .NET

حدودا 6 ماه بعد از انتشار NET Standard 2.1. خبرهایی را پیدا کردیم که NET Framework. و NET Core. در یک پلت‌فرم واحد NET. به نام NET 5. قرار گرفته‌اند. اکنون ما به استاندارد نیاز نداریم زیرا دو پلت‌فرم ما در تلاش برای تعریف برابریی هستند که در واقع یکی شده و یکسان می‌باشند.

اکنون این واقعیت را نیز داشته باشید که NET 6. می‌خواهد تا شامل پلت‌فرم Xamarin باشد. حالا تمام نمودارهایی که از NET Standard. دیدید، جایی که سعی کردید تا ستون‌ها را دنبال کنید تا ببینید از کدام نسخه پشتیبانی کنید دیگر نیستند زیرا حالا فقط یک سطر وجود دارد، که NET 6. است.

در آینده فقط یک پلت‌فرم .NET وجود خواهد داشت. دیگر نه Xamarin، نه NET Core.، نه Mono، نه NET Framework. هستند. فقط NET. است.

پس باید استفاده از NET Standard. را متوقف کنیم؟

این چیزی است که اخیرا زیاد پرسیده می‌شود. اگر همه این‌ها یک پلت‌فرم شوند، آیا شروع به نوشتن کتابخانه‌ها برای NET 5. می‌کنیم؟ پاسخ خیر است. NET Standard. هنوز به عنوان نوشتن روشی برای نوشتن کتابخانه‌هایی که در NET Framework. یا نسخه‌های قدیمی‌تر NET Core. اجرا می‌شوند موجود است. حتی امروز، هنگام انتخاب نسخه NET Standard. برای یک کتابخانه، سعی می‌کنید کمترین تعداد مورد نظر را انتخاب کنید تا مطمئن شوید از بیشتر پلت‌فرم‌ها پشتیبانی می‌کند. NET 5. هنوز به عنوان مثال NET Standard 1.0. را پیاده‌سازی می‌کند، بنابراین هر کتابخانه‌ای که استاندارد قدیمی را هدف قرار می‌دهد هنوز بر روی آخرین نسخه NET platform. اجرا می‌شود.

چند سال دیگر این طور نخواهد بود که بگوییم "اوه این کتابخانه برای NET Standard 2.1. است، آیا برای NET Core 2.1. است؟ نه این برای NET Core 3+. است... چه کسی می‌داند". در عوض این‌گونه خواهد بود، اوه این کتابخانه برای NET 5. است، پس در NET 7. بدون مشکل کار خواهد کرد.